Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds ability to fire Trigger listeners immediately. Fixes #10869 #10877

Closed
wants to merge 1 commit into from

Conversation

kentontaylor
Copy link

No description provided.

@ncoden
Copy link
Contributor

ncoden commented Jan 22, 2018

Hi @kentontaylor, Thank you for your PR, I'll review it tonigh.

@ncoden ncoden self-requested a review January 22, 2018 17:47
@ncoden ncoden added this to the 6.4.4 milestone Jan 22, 2018
Copy link
Contributor

@ncoden ncoden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @kentontaylor !

Your PR works, but seems a bit hacky. Foundation should just try to initialize himself as soon as possible. A iDontCareInitializeNow() function would only fails in most of its use cases.

As far as I know, there is no reason to wait for all scripts to be loaded. When html is dynamically added we expect it to be initialized manually anyway.

I replaced $(window).on('load') by $(document).ready() and it seems to work. Unit tests runs and all components are fine. However, I'm not totally confident with this.

@colin-marshall @Owlbertz @brettsmason Do any of you know Trigger enough to ensure that using $(document).ready() does not introduce weird bugs ?

@kentontaylor
Copy link
Author

Hi @ncoden, thanks for the feedback!

Yes, we noticed too that swapping window.load with document.ready resolved the problem, but were also similarly spooked by that :)

So instead, my goal became introducing the capability we needed as optional, while avoiding possible regressions in downstream components/behaviors that may have come to rely on the timing of window.load.

Looking forward to the others' input. Thanks again!

@Owlbertz
Copy link
Contributor

I really don't want to sound rude, but the broken unittests indicate an issue to me.

@ncoden
Copy link
Contributor

ncoden commented Jan 24, 2018

@Owlbertz The broken unittests comes from elsewhere. I did not figured out from where, they works in local.

@DanielRuf
Copy link
Contributor

@Owlbertz The broken unittests comes from elsewhere. I did not figured out from where, they works in local.

I really don't want to sound rude, but the broken unittests indicate an issue to me.

#10886

@DanielRuf
Copy link
Contributor

Closes #10869

@DanielRuf
Copy link
Contributor

DanielRuf commented Mar 24, 2018

@ncoden I guess this is another candidate for the new onload helper utility.

@ncoden
Copy link
Contributor

ncoden commented Mar 24, 2018

onLoad is already used for this (see #11077). The issue here is that $(window).on('load') is triggered once external ressources are loaded. Problem is that some external ressources are not useful at all for the page to be usable and can take a long time to load.

So we may have to use $(document).ready() instead. Problem is: it's hard to figure out what this could break in the current users' projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants