This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Not so much a question of a modular Rails system, as much as it is a question of a well designed Rails system… but can anyone speak up about how they’re using turbo streams to achieve rich UX, in a way that is not convoluted?
Here’s the tension I’m seeing:
• On a given show page, that is styled by the product / design teams as more of a “live edit” feel… we’re using turbo streams to respond to updates with selected updated components on the page. Eg, update the buyer sends back a flash message via turbo, whereas updating a quantity in a table cell will stream back a flash message AND a replacement for the row (as one quantity affects others in the row).
• Back-end business logic governs whether a shopping cart is valid and can proceed to order status. The “order” button state is tied to an “orderable” flag on the shopping cart model.
• However, there are a handful of user operations that can affect the “orderable” status, and which then should include an updated “order” button (enabled or disabled, as the case may be).
How can I structure my UI/application to update that button component when the model attribute “orderable” changes?
I feel something lacking… and I’m groping my way towards some look-up mechanism, whereby the UI/application layer can ask some map, “here’s the old state, and the current state of the model… what UI components do I need to update?”