[LiveComponent] `_willDataFitInUrl` does not calculate correctly

[norkunas]

Based on my findings:

• It doesn't properly serialize to string value when this.dataValue contains nested objects, because in my case it Object.values(this.dataValue).join(',') returns: [object Object],form_builder,[object Object],false,form_builder.slug,form_builder.title,NJQRgieAbBmGi0vFxpGlGJVYTrJpA0se7rz4rDTl4N8=
• It doesn't take into account params and only uses this.dataValue to determine it

So in my case when editing a big form with a LiveComponent it always fails to render because it does GET requests with too long query string

[kbond]

Interesting, what are the downsides of always using POST?

I guess this will be a problem for component_url() as well?

[norkunas]

From my side I don't see any difference, it's just a different request method so currently just overrode that method to always return false :)

[norkunas]

Oh maybe I see a problem with GET request: it wouldn't allow to send an attached file in form

[kbond]

I believe the primary reason for allowing GET was to make the component_url() work with Turbo but @weaverryan can speak more to that.

I think, at least when using the live-controller, we should always use POST but maybe there are some reasons we can't do that I'm not aware of.

@weaverryan, what do you think about dropping component_url() entirely? Then we can only support POST. It isn't documented and it was basically broken since day-1 until yesterday 😄.

[weaverryan]

GET request is much more proper. When we make a re-render ajax call, we are saying “given this data, please give me the appropriate html”. That should be GET :). That also makes the request cacheable (not realistic likely for very dynamic components, but certainly realistic for less dynamic).

But, of course, eventually GET can’t work because there is too much data (and also file uploads - that is not something I’ve checked into yet). In that case, we fallback for POST.

Also, this bug seems fixable, right? I haven’t quite digested the problem, but we should be able to determine how long the query params are before making the request and switch accordingly. That’s how it works now… except that it apparently doesn’t work quite right yet ;).

[norkunas]

Would it be a good solution then to use JSON.stringify for serializing this.dataValue and then concatenating it with params.toString() and checking total length or do you have something other in mind?