Ajax-Submitting an Entire Form

Hi, it seems that by rendering a partial view you lose all the stimulus controllers that normally work if you render by extending from the base structure. I have difficulty with ui-datepicker and google place autocomplete both used with webpack, any advice ? thanks

Yo @pasquale_pellicani!

Are you making an Ajax call that returns a "partial" page, then inserting that onto the page (like we do in this chapter)? If so, everything "should work" :p. What I mean is: Stimulus is smart: if you add some HTML that contains Stimulus logic into the page, it will "just work" no matter how it go onto the page (Stimulus is actively watching in the background for new stimulus controllers to get added to the page).

So, in your case, something else might be going on. Can you tell us a bit more what you're working on and what's going wrong and when? And any libraries you're using for datepicker or autocomplete.

Cheers!

Of course and thanks for asking, I'll start by saying that if I load the view with a normal call the controller for the autocomplete place and the.js file with the selector for the datepicker work normally. I got the stimulus controller to have the autocomplete effect from here while for the datepicker I created a ui-datepicker.js file and loaded it with the addEntry instruction in the webpack file and then loaded it into the page header
ui-datepicker.js content below:

import $ from 'jquery';
import datepickerFactory from 'jquery-datepicker';
import datepickerITFactory from 'jquery-datepicker/i18n/jquery.ui.datepicker-it';

// Just pass your jquery instance and you're done
datepickerFactory($);
datepickerITFactory($);

$(function() {
    console.log('document (as function) is ready I load datepicker!!!');
    $('.fc-datepicker').datepicker();
    $.datepicker.regional['it'];
});

....I've been going crazy for 2 days, thanks in advance ^_^

Hey @pasquale_pellicani!

Ok, we can figure this out :). First, is the places autocomplete working after the Ajax call? I would expect yes, because it's properly using Stimulus (more explanation below), but I'm curious about that.

Ok, so the problem is... kind of a generic JavaScript problem, which Stimulus helps a lot. In your situation, the flow is like this:

A) The initial page loads
B) Your JavaScript in ui-datepicker.js is called, which initializes the .datepicker() on the .fc-datepicker element (this probably includes adding a bunch of new elements around that element to support the date picker).
C) You reload part of the form, which replaces the entire form, including the .fc-datepicker element and all of the fancy date picker stuff.
D) ... but your JavaScript to initialize the date picker never runs again... so it never reinitializes.

The fix is to wrap this logic inside of a Stimulus controller:

// assets/controllers/date-picker-controller.js
import $ from 'jquery';
import datepickerFactory from 'jquery-datepicker';
import datepickerITFactory from 'jquery-datepicker/i18n/jquery.ui.datepicker-it';

datepickerFactory($);
datepickerITFactory($);

export default class extends Controller {

    connect() {
        console.log('document (as function) is ready I load datepicker!!!');
        $(this.element).datepicker();
        $.datepicker.regional['it'];
    }
});

Now, when you're rendering this field, we don't need an fc-datepicker class anymore (you can add one for styling if you need it, but our JavaScript doesn't need it). Instead, we need a data-controller attribute that points to our date-picker controller:

{{ form_row(form.theDate, {
    attr: stimulus_controller('date-picker')
}) }}

That's it! You should see a data-controller="" attribute on your actual input element on page reload. NOW here is the flow:

A) Page loads
B) Stimulus sees the data-controller="date-picker" and calls your controller
C) Your controller's connect() method is called. And this.element points to your input. So, you initialize the date picker fanciness.
D) You reload your form via Ajax. This removes the old date picker element entirely. You are, for a millisecond, back to a form without the fancy date picker!
E) But, Stimulus notices that the old data-controller input element was removed and a new one was added. So, it calls connect() again, and you initialize the data picker on the new element.

That's it! Let me know if this help :)

Cheers!

Hi all, sorry, I don't know whether to be ashamed or something, practically everything worked but the z-index of the modal won over the doms of the datepicker and the place autocomplete XD

p.s.
However, thanks Ryan I used your suggestion of the new controller for the ui-datepicker, I take this opportunity to ask another question, is the proliferation of controllers correct? Or is the ideal to consolidate everything into a single controller?

Woo! I'm always happy if it's something simle :).

I take this opportunity to ask another question, is the proliferation of controllers correct? Or is the ideal to consolidate everything into a single controller?

There's no perfect answer about where to "draw the line" between putting 2 things into 1 controller of having 2 controllers, but yes, in general, I think that more controllers is better... and usually just because it makes your life easier (so do whatever makes life easier!). One big benefit of a controller is that it is tied to an element and then you can reference it with this.element. So, to give an example, if you, instead, had a controller that you associated with your form element, you would then need to (in connect()) find all of your date pickers - e.g. this.elemenet.querySelectorAll('.fc-daterpicker'), loop over these, and initialize the date picker on them. That's just more work :P. And also, if some new HTML gets loaded into your form element (but the form element itself remains), any new date picker element will not be "noticed" and reinitialized.

I hope that helps :)

Cheers!

Hey Krzysztof,

We have a separate screencast about uploads including Dropzone though that does not leverage Symfony UX: https://symfonycasts.com/screencast/symfony-uploads - I think you might be interested in that screencast too.

But if you're interested in Symfony UX Dropzone, please, take a look at the example in the official docs:
https://ux.symfony.com/dropzone

And more details are explained in https://symfony.com/bundles/ux-dropzone/current/index.html

I hope it helps!

Cheers!

Hey @pasquale_pellicani!

My go to solution in general these days is actually FormData and then applying that to fetch(). And FormData works fine with file uploads and will set the Content-Type to multipart/form-data for you. So yes, I would say that FormData IS the definitive solution. Things like jQuery's serialize predate it, which is why they exist / existed. But these days, I go for FormData.

Let me know if that works for you - or if not, what's going on :)

Cheers!

Hi, in reality I am taking up code from a project born about 10 years ago, therefore with sy3.4 where I intend to improve the code as I move on, but I must recognize that my predecessor knew a lot about js, to manage a form including an image to upload (optional) uses two separate forms in same view, the first is managed with the form.seralizeJSON fetch, the second in cascade with the new FormData() technique, really an excellent job ^_^ thanks for your replies

Hey @escobarcampos

Yes, jQuery is still a thing, the team behind it seems active and working on the library. However, I don't recommend using it. With Stimulus + some vanilla JavaScript you can do wonders. Also, with Symfony UX and Live components, it's likely that you won't even need custom JavaScript

Cheers!