Multiple Updates in one Stream

That's very nice! 😀

Hey @Brandon!

Sorry for taking so long to respond! This is the type of thing that simply "should work" with Stimulus: it's built to keep working even after content is changed in the site. So my guess is that there's just some small issue with how that Stimulus controller is set up :). To "listen to changes on the form", are you adding the event listener in JavaScript via the connect method of your controller? Or are you adding data-action attributes to each element that should trigger the auto-submit. If you're doing the first, that would cause this problem because the listeners are only registered once. So when some new HTML is added, there are no listeners added to the new elements.

Anyway, I'm doing some guessing. But if you're still having issues and this doesn't help, show me the template code & Stimulus controller and I bet we can figure it out :).

Cheers!

Ryan,
I ended up doing this:

<turbo-stream action="append" target="quotes">
    <template>
        <span data-controller="submit-on-change">
            {{ include('subs/_quotes.html.twig') }}
        </span>
    </template>
</turbo-stream>

And just adding the controller to the Stream. It works well enough, but obviously the controller connects twice in my console.

The listener is in the connect method, this is it:

connect() {
    // Target all forms with the specified class
    const forms = document.querySelectorAll('.form-with-submit-on-change');

    forms.forEach(form => {
      // Add an event listener to each form's input fields
      form.addEventListener('change', () => {
        // Submit the form when an input field changes
        form.requestSubmit();
      });
    });
  }

A small side note, this didn't work well at all for me until I changed 'form.Submit()' to 'form.requestSubmit' which I found in the forum's, someone else had the same issue I was having. I don't think that is affecting my original issue, but I thought I'd mention it.

Lastly, in my template, on my 'index.html.twig' in my top column div is where I initially connect this controller. My page then contains two Turbo Frames, which I also want to mention, the second column on my page contains the frame where a form is added to the page, but it doesn't listen to it until a page refresh. When you change the form in the second column, it updates the first column with the another Turbo Frame.

Hey @Brandon!

Ah, perfect! Seeing your Stimulus controller is what I needed :). So yes, the problem is what I described above. Let's assume that you haven't added the span data-controller="submit-on-change"> to the <turbo-stream>. In that case, here is the flow:

A) You load the page. The connect() method of submit-on-change is called. It finds all of the correct form elements inside... then finds each field. For each field, it registers a change event.

B) Then, via the <turbo-stream> you replace the <form> elements on the page with NEW <form> elements. However, importantly, the parent element that has the data-controller="submit-on-change" was NOT replaced. And so its connect() method was not called. But now, those new <form> elements? They don't have any change listeners on their fields. That's because all of the old form fields were just deleted from the page and brand new fresh elements were added. And those fresh elements do NOT have any listeners attached to them.

The "proper" solution might be annoying in your situation, but here it is: do not "find" elements from inside connect() and manually register event listeners. Instead:

1) Add the data-controller="submit-on-change" to each <form> element where this is needed.

2) add data-action="change->submit-on-change#submit() to every form field where you want this behavior.

3) create a submit method that is simply:

submit() {
    this.element.requestSubmit();
}

(Side note, yes requestSubmit() is correct - it's a weird thing where calling submit() doesn't dispatch a submit event and so Turbo or other JavaScript can't hook into it).

So, this is what I'd recommend and it will "just work". Otherwise, you're trying to fight against Turbo. If adding the data-action is to every field is annoying, you could implement a finishView() method in your form that loops over every field and adds this to the field's attr. This old tutorial - https://symfonycasts.com/screencast/symfony-form-theming/controlling-vars-with-finish-view - is still pretty relevant. You can also foreach ($view as $childView) to loop over every field to get the child FormView. Just be wary that more work would need to be done if you have a more complex form with fields that go beyond 1 level deep.

Cheers!

Thanks jgrasp - it's on my list to add a note about this! I asked for the latest tag to be created for that library... but haven't had a chance to add this note yet!

EDIT: Nevermind, I DID have a note, but you're correct that I still had this mistake in my updated code. This was also just fixed on the main repo. Thanks!

Hey @Jay Gee!

Thanks for the post! I think Turbo Streams (and frames) are still so new that there are undoubtedly better ways to do certain things - I was pushing things pretty far, but mostly thinking of the "best ways that *I* could think of doing something"... and I almost definitely didn't always end up with the best way. I'm glad you're thinking critically to challenge what I came up with :).

Cheers!

Hey Matthias K.!

That's.... an interesting idea! It's a bit outside of my wheelhouse... but it could be kind of fun to try. We'll add it to our idea list - but it wouldn't be something that would happen too soon :).

Cheers!

Hi, Michael!

To my knowledge, there is no limit as to how many templates you can return from a request. This might be a matter of practice: When would a response become too large, or the number of templates so big that it would take noticeable time for the JavaScript to parse it. In a real world scenario, I can't imagine this becoming an issue!