Intercooler.ready is executed on document.ready #320

trailmax · 2020-05-22T23:47:53Z

From documentation I understand that Intercooler.ready should be called on completion of successful DOM load.
However I see that this is also executed on page load, without any AJAX calls whatsoever. This is causing issues with element bindings and is totally unexpected.

See this reproduction:

<html>
<head>
	<script src="https://code.jquery.com/jquery-3.1.1.min.js"></script>
	<script src="https://cdnjs.cloudflare.com/ajax/libs/intercooler-js/1.2.3/intercooler.js"></script>

	<script>
		Intercooler.ready(function (rootContent) {
			console.log("Intercooler.Ready");
		});
	</script>
</head>
<body>
</body>
</html>

On page load in console you'll see the log output.

Is this an intended behaviour?

The text was updated successfully, but these errors were encountered:

adamstep · 2020-05-23T00:08:51Z

I believe it is intended, the initial page load is also a DOM load so it makes sense. Any bindings that need to happen after Intercooler swaps content should also happen when the page first loads.

Can you post a specific example where your having issues? I may be able to help.

trailmax · 2020-05-23T00:56:53Z

@adamstep I was under impression for Inetrcooler.ready to trigger DOM needs to load through Intercooler, not any other way.
So does it mean that DOM loaded through other means will also trigger Intercooler.ready? I'm talking about something like this:

        let request = $.get("~/myEndpoint");
        request.done(function (html: string) {
            $('#reloadme').append(html);
        });

As for concrete proglem, it is element double binding. We have a function that binds all the elements that needs binding, something like BindAllElements(selector) where it goes through selector and does the bindings. On document.ready we call BindAllEmenents('body').
And then every time we reload parts of pages we call BindAllElements('#reloadme').

Now we are trying out Intercooler on small part of our application and do this:

Intercooler.ready(function (rootContent) {
            BindAllElements(rootContent.selector)
    });

When the page is loaded it effectively calls BindAllElements('body') for the second time, after we already done that first binding. Thus causing double bindings on elements.

For now I've worked around like this:

Intercooler.ready(function (rootContent: any) {
        if (rootContent[0].tagName !== "BODY") {
            BindAllElements(rootContent.selector)
        }
    });

But this feels very hacky, hence my question here.

jsampson · 2020-05-23T15:21:29Z

I think this is a case of the docs not matching the intent. The reference page does indeed say " to be run on the top level of all content that is swapped into the DOM by intercooler." However, I've always thought of it as simply meaning "when Intercooler is ready," i.e. Intercooler has processed all the elements on the page (either when first loaded or when swapped in). In your example, I would simply get rid of the document.ready and eliminate the if inside Intercooler.ready.

Can we consider this a documentation bug and fix the wording rather than changing the behavior (which other Intercooler apps already depend on)?

1cg · 2020-05-23T16:01:44Z

Yeah, this isn't documented that well and needs a fix.

Basically Intercooler.ready is the intercooler replacement for $.ready, except you have to do all initialization within the elt passed in, rather than globally as you would with $.ready.

1cg · 2020-05-23T16:02:35Z

I wanted to have one place where you did your initialization code for both the initial body load as well as any AJAX calls.

baumann74 · 2020-05-23T16:59:00Z

Hi Max. Maybe I misunderstand your problem but do you mean "binding" of intercooler elements?.That should happen automatically on page load and you should not have to do anything as long as you use the "ic" tags. You should use the method "Intercooler.processNodes" for wiring in elements in the HTML that you receive in a AJAX request. No need for the Intercooler.Ready method as I see it. Anders

…

On Sat, May 23, 2020 at 7:02 PM chg20 ***@***.***> wrote: I wanted to have one place where you did your initialization code for both the initial body load as well as any AJAX calls. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2AHGFLB4DPLREYOTMRI3TRS7XSXANCNFSM4NIFZORQ> .

trailmax · 2020-05-25T09:49:48Z

Hello Anders,

By element bindings I mean our elements, not Intercooler's. We use KendoUI for datepickers, colourpickers, etc. We need to tell Kendo what should be a datepicker, what should be a colour picker, etc. So we have loads of bits of code that do:

       $selector.find('input.datep').kendoDatePicker({
            format: "dd/MM/yyyy"
        });
        $selector.find('input.datetimep').kendoDateTimePicker({
            format: "dd/MM/yyyy HH:mm"
        });
        $selector.find('input.colorPicker').kendoColorPicker();
        // etc.

When new bits of DOM are loaded we need to execute those binders on the new elemenets, otherwise Kendo does not pick it up. As far as I can see Intercooler.processNodes only deals with Intercooler bindings, nothing external. Hence the usage of Intercooler.ready.

As for replacing $.ready with Intercooler.ready - we can't do that, as we have hundreds of pages where sometimes we are binding page-specific elements retest or rewrite all those pages is not an option.

So if you are saying this is an intended behaviour, we'll just keep what we have with the test for BODY. Unless there is a better way you can suggest.

Thanks for looking into this!

baumann74 · 2020-05-25T10:31:57Z

Hi Max. Now I understand. Yes, I do have a suggestion because in general Intercooler.ready should be your last resort since it is a general method and it is called for all intercooler requests. I suggest that you put the binding code together with the HTML that you want to bind and which you receive as a response for an intercooler request. The trick is that the browser automatically executes <script> tags which are dynamically added to the page via the DOM .So your server response should look something like this: <div> ..... </div> <script> // binding code. </script> I am using this pattern and it works well. Anders

…

On Mon, May 25, 2020 at 12:50 PM Max Vasilyev ***@***.***> wrote: Hello Anders, By element bindings I mean our elements, not Intercooler's. We use KendoUI for datepickers, colourpickers, etc. We need to tell Kendo what should be a datepicker, what should be a colour picker, etc. So we have loads of bits of code that do: $selector.find('input.datep').kendoDatePicker({ format: "dd/MM/yyyy" }); $selector.find('input.datetimep').kendoDateTimePicker({ format: "dd/MM/yyyy HH:mm" }); $selector.find('input.colorPicker').kendoColorPicker(); // etc. When new bits of DOM are loaded we need to execute those binders on the new elemenets, otherwise Kendo does not pick it up. As far as I can see Intercooler.processNodes only deals with Intercooler bindings, nothing external. Hence the usage of Intercooler.ready. As for replacing $.ready with Intercooler.ready - we can't do that, as we have hundreds of pages where sometimes we are binding page-specific elements retest or rewrite all those pages is not an option. So if you are saying this is an intended behaviour, we'll just keep what we have with the test for BODY. Unless there is a better way you can suggest. Thanks for looking into this! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2AHGDF37W5BFG72MOR2SLRTI5MVANCNFSM4NIFZORQ> .

trailmax · 2020-05-25T12:51:35Z

@baumann74
I see, I'll give this a try, but I sense repeating the binding code on every partial page smells of DRY violation.

Thank you for your time and help on this, very much appreciated!

Cheers,
Max

trailmax closed this as completed May 25, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Intercooler.ready is executed on document.ready #320

Intercooler.ready is executed on document.ready #320

trailmax commented May 22, 2020

adamstep commented May 23, 2020

trailmax commented May 23, 2020

jsampson commented May 23, 2020

1cg commented May 23, 2020

1cg commented May 23, 2020

baumann74 commented May 23, 2020 via email

trailmax commented May 25, 2020

baumann74 commented May 25, 2020 via email

trailmax commented May 25, 2020

Intercooler.ready is executed on document.ready #320

Intercooler.ready is executed on document.ready #320

Comments

trailmax commented May 22, 2020

adamstep commented May 23, 2020

trailmax commented May 23, 2020

jsampson commented May 23, 2020

1cg commented May 23, 2020

1cg commented May 23, 2020

baumann74 commented May 23, 2020 via email

trailmax commented May 25, 2020

baumann74 commented May 25, 2020 via email

trailmax commented May 25, 2020