Well, that made the JS way simpler.
Adds a lot of classes though. Maybe we could do it based on column index instead, but this will do for now.
table.hide-col0 { td:nth-child(0) { display: none; } }
Visibility was way simpler, but the table doesn't recalculate column widths until you use display:none;
This is now using the same method as the old products screen.
But we still need to update colspans..
The cols could have been a lot cleaner with simple classnames, but I preferred to mark up in a way that reveals the purpose (otherwise they could be used for styling).
It doesn't seem to be any faster comparing querySelector('[data]') vs class, or iterating through the dom nodes.
They were already counted as changed by the javascript, but didn't have a 'changed' class to indicate it.
The reason they are 'changed', is because the dropdown has no blank option, and is forced to select the first item in the list.
This is purely to cover the case of invalid data, but should help a lot when debugging data issues. I don't think it's any less efficient, because the extra 'classList.toggle' calls don't do anything on unchanged fields.
Yay, now it works. Not sure the best way to show loading yet.
- currently the Turbo loading indicator shows which is better than nothing (blue bar at top)
- ideally we could show a small spinner over the image thumbnail. need to write some stimulus to hook into turbo lifecycle I guess.
- or we could activate the frame-level loading overlay. refactor loading_controller a bit so that it's applied on the container, then hopefully we can just call change->loading#showLoading. the turbo_stream response could dectivate it.
When elements are removed from the DOM, they remain in the recordElements array. But we can simply ignore them.
We have to wait until after rails-nested-form:remove is completed before toggleFormChanged.
hmm It would be even better to remove them from the array..
- Styling(in red) for the remove button/link in view
- A remove method to the bulk_form controller
- removes elements from the Dom
- removes changed elements from the binded Array in controller
- so that menu that indicates changes disappear and blured elements
- resume to non blurring state
- Added the corresponding specs
- test with one, two variants
- test with two different products
We've found that we just can't rely in StimulusReflex (and the underlying WebSockets stack) to guarantee a response to a request.
Because of this, there was intermittent issues when the server was overloaded with large requests, and the response never arrived, leaving an infinite loader, and a poor user wondering if anything was still happening.
Watch out, HAML will strip an attribute with boolean false, so we need to use a string. Or reconsider using false as a default value..
I wish Jest had the rspec concept of `let`.
