This naming scheme removes some duplication which is nice, but it's a little strange and results in a longer name overall. I don't like it very much because:
- filenames don't include the component's actual name. This makes it slightly harder to find them in my text editor (but I'd probably get used to that)
- the namespace and class naming isn't exactly right. This is _the_ vertical_ellipsis_menu, not a subcomponent.
- the stimulus controller name is now longer, adding more cruft to the HTML.
Lots of discussion here: https://github.com/ViewComponent/view_component/discussions/67
People tried to come up with a better way (and I was tempted to try myself). It seems this approach won. I guess it's not so bad if your component names are shorter.
Javascript hasn't been moved in, as we don't seem to be set up for that yet.
We could make it smarter, and pass in an array of parameters to build the links (as in _order_links.html.haml). But why make it complicated if we don't need to?
It looks like the disabled-bg colour was being used for pagination, but I can't see where. This way we should be able to apply the styles more consistently in the future.
I chose to use the 'elements' collection rather than choosing which elements to include (ie this supports inputs, textareas, buttons and anything else I didn't think of). It could be a bit simpler if we assume the element is a form. Even simpler if it's a fieldset (that has a disabled property). But I didn't want to limit it too much.
Unfortunately JS is quite ugly compared to Ruby. And 'prettier' made it uglier in my opinion.
It's not great to have Stimulus controller rendering markup on `connect`
Stimulus is intended to add behavior to existing markup.
Plus add some documentation
It added specificity but had no use.
I reviewed a couple of screens to make sure:
- /admin/orders/Rx/customer
- /admin/properties/new
I have to confess I don't know how Spree::Admin::BaseHelper is included, or where it's used.
Best viewed with whitespace ignored.
I decided not to invest the time to figure out how to test this..
The messages should have the same effect as the 500 error, but not technically a 500 because it's not handling a HTTP response. The documentation seems to state this covers server-side errors only (not network errors for example). I couldn't find any way to handle network errors with action cable.
