I'm not happy about it, but we need it to be a standard link to make it work. I assume it's because BulkFormController.preventLeavingChangedForm() isn't smart enough.
This reverts commit 91f0a80189.
duh.
Turbo cleverly pre-fetches GET requests to save loading time. But that resulted in dozens of unwanted clones.
Attack of the clones!!!
I checked: even though this route predates the new products screen, it wasn't being used anywhere else. The old products screen uses the API instead.
This page is big enough and it's hard to see how everything works. So links work like links by default (eg edit and clone). Other links and forms are special, and will reload only the frame: this is now explicit in the code.
That was surprisingly easy. Note that it's still shared with SR.
It hides a bit early though: when the web response returns, but before the DOM has been rendered. Something to optimise in the future.
Now the filters, pagination and product forms submit and load within the frame, and work perfectly, yay!
It's still building the whole page on the server.. I think we need Turbo Streams if we want to send back just a partial.
Forms now load without a full page rebuild.
This is not really faster, but a bit smoother because it avoids a full page render in the browser. The default Turbo loading indicator is shown (blue line at top).
But the bulk_update form breaks... hmm
On to the next level!
_learn and _connect seem to appear at the top of the homepage (and not as pane). Also, there was some hard coded URLs which seems not to be used, as the translations in the Configuration/Content section seem to work correctly.
I'm not sure how to trigger this error, and triggering an update error message seems appropriate too - it's sort of an edge case, perhaps this is a valid approach
I've checked staging, and I could not find this message, nor the entry in the en.yml file - I think we're not rendering this message currently, hence, the removal.
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.
The check for invoiceability is already done by the reflex triggering
the job. Let's DRY the code, save time and be more flexible in the
future.
Also checking the order of actually generated PDF pages.
