* wip - <PodcastArticle /> component.
* Added filler user avatar for other article types.
* Added <LoadingArticle /> component.
* wip
* wip on <Article /> component.
* Added <Article /> component to barrel file.
* Deleted assets from dummy storybook assets folder.
* Updated podcast article story avatar.
* More work on <Article /> component.
* Refactoring Storybook stories.
* Refactored so main component is just the <Article /> component.
* Added a missing video article property.
* Some refactoring of <Article /> component.
* Added Storybook knobs addon.
* Now <Article /> component supports an isBookmarked prop.
* Fixed podcast Storybook story.
* Made the knobs Storybook addon the first tab
* Added more <Article /> Storybook stories.
* More <Article /> component tweaks.
* Added publish time to <Article /> component stories.
* Made the timeAgo function compatible with Preact.
* Added loading="lazy" attribute to <img /> in <Article /> component.
* Added <Article /> Storybook story for past published date.
* Fixed publish date for <Article /> story data.
* Scrapped random avatars.
* Added snapshots for <Article /> component.
* Added snapshots for <LoadingArticle /> component.
* Now test article entities are shared.
* Fixed some wording of Storybook stories.
* Breaking up Article.jsx to make codeclimate happy.
* Now <Article /> component receives icon props.
* Added knobs for <Article /> icon props.
* Added *.stories.jsx to codeclimate exclusion list.
* Added **/*.stories.jsx to codeclimate exclusion list.
* Alright now we have the good glob for excluding Storybook from codeclimate 😆
* Added org headline changes from low hanging fruit PR.
* Updated <Article /> snapshot for org headline.
* Add StimulusJS 1.1.1
Because:
- Internal will likely need more interactivity going forward
- Vanilla JS and jQuery are great, but aren't quite as organized as we
might like
- Stimulus fits our model of what internal should be (imo)
- Adopting Preact or something with templating would require rewriting a
bunch of erb (that is currently working just fine)
Stimulus is a JavaScript framework that directly compliments turbolinks
and the approach vanilla Rails takes to JavaScript. I've set it up to
specifically be used in the internal views where we are currently using
jQuery and vanilla JS. I think we should chip away at the vanilla JS
currently in place with this, which appears to be both scalable and
pragmatic exactly the sort of tool we want for building our internal
tools.
* Replace crufty article JS with Stimulus
I'm swapping out some of the stuff going on in article_script.erb with
some StimulusJS, it seems like a good test case for Stimulus.
This lets us organize the code a little more intentionally and hopefully
fixes a small performance complaint that Michael had.
* Rename uncommunicative methods
* Add unit tests for Stimulus classes
* Move Stimulus code to javascript/internal
rails-assets.org is often down, and apparently has been down intermittently since yesterday.
In addition to this the only thing the gem does is literally to add `honeybadger.js` to the assets path:
```ruby
gem_path.join('app/assets').each_child.to_a
```
Hence we can ditch the gem and use the library directly.
* Improve format and clarity of the docs [ci skip]
While this change produces a lot of git noise by enacting what seems
like an arbitrary linewrap on most of the files in the documentation it
will result in better version control and tracking of the changes in the
documentation.
For example, as it currently stands, if one was to make a
PR to move a comma in a sentence because each paragraph in most of the
files is on a single line, that small change would look in the git
history like the author had modified the entire paragraph. In reality,
this author just moved a comma.
This change also includes a significant number of modifications to the
more article-esque docs. Many of these docs were written in a sort of
stream-of-conciousness and aren't as easy to read as they could be.
Hopefully this is the first of several readability changes. If we could
get these docs to a more accessible reading level, we would probably see
an increase in contributions. :)
* Delegate markdown wrapping to Prettier
* Add linewrapping explanation in the docs [ci skip]