Can't grab `w-slider-dot` ! Any suggestions?

Hi all I have issue with grabbing w-slider-dot. When I inject JS code into project all works as it should but when code is implemented in page setting WF ignore it as if element doesn’t exist. Can someone explain why this happened an how it can be solved?
More in video below.

The slider dots elements get created at runtime, meaning that they didn’t exist in the moment you were running your code.

What you can do is wrap your JS code in either

$(()=>{
    YOUR-CODE-HERE
})

or

window.Webflow = window.Webflow || [];
window.Webflow.push(()=>{
    YOUR-CODE-HERE
})

Give it a try and let us know :wink:

1 Like

Thanks @Jeandcc that worked but I do not understand why I need it and what it does when is added to an array!

After your provided comment I have test it with simple setTimeout and it worked too. My confusion was that elements are rendered into DOM first and JS is running after and it didn’t worked even I have add DOMContentLoaded listener to test it. whats more WF is SSG so it should be accessible as page is pre-rendered … :face_with_raised_eyebrow:

Is there any doc I can read in what cases this hack need to be used? Until now I didn’t need it when implementing custom JS.

Thanks for solution :wink:

By using the code I shared, you are basically saying that your code should only be run after the page is “ready/initialized”. That can be done with jQuery.ready or with a nice functionality that comes with Webflow JS code that gets added to your page. (more info below)

When you add that code inside the window.Webflow array, you are basically adding a function to an array of functions that should run once Webflow is done initializing its own code and components. Webflow code runs once the page is loaded, creating your sliders, tabs and etc, and once Webflow is done with all its work, it then goes through that array to run all the functions that were added to it.

While this is partially true (most of your page is indeed statically generated), some functional components from Webflow (such as slider, tabs, lightboxes…) need to be properly initialized on the client side since they rely on client-side javascript to simply ‘work’. That’s why some some DOM elements and attributes will only exist after you actually load the page.

You can easily see what I mean by accessing view-source:https://slider-fun-1.webflow.io/slider-02 (Replace the url with the new url of your project). By accessing that link, you will see what’s the actual content that Webflow sends from its servers. All the rest is generated at runtime (such as the slider dots elements for example)

I also recommend you accessing the unminified webflow.js file from you site, so you can see all the modules from Webflow that have some sort of client-side logic attached to it. Just search for Webflow.define(' in that JS file and you will be taken to all module initializers. (Keep in mind that it will only show the modules that you actually use in your site: If you didn’t have sliders in your site, you wouldn’t see the initializer for the Slider component)

Unfortunately no, I have this feeling that Webflow doesn’t really focus on providing a lot of features to Software Developers. Their back-end API hasn’t been updated for a long time, and there’s no documentation for any sort of integration with their client-side code. All of the things I talked about in this thread I had to learn by myself by simply reverse engineering their code, or with the help of fellow developers from this forum.

However, you can simply start using the window.Webflow.push for all your future development, as this will ensure that all your code will only run once Webflow is done with setting up the page. This should not impact the rest of your code in any way.

1 Like

hi @Jeandcc thank you for comprehensive response. I have read some articles yesterday on forum and notes I have in my “drawer” and most of these were related to IX2 reinitialisation.

The question is how is this hack future proof IF (not when) WF Logic will be ever released and if, how powerful it will be mean if it will be comprehensive or half baked product.

Agree with statement about documentation for developers and WF API.

Thanks again and have a great day

If you want something that is close to being future-proof, just go with the jQuery approach $(()=>{...}): this approach allows you to not have to rely on anything that is specific to Webflow, and as long as Webflow continues to use jQuery in its sites, this will continue to work.

1 Like

sorry for jQuery noob question but isn’t syntaxtic sugar of JQ compiled to vanilla so push() will be more stable? But I understand what do you mean with use of jQ as I have faced a few issues when JS didn’t worked in WF but worked with jQ syntax.

The vanilla JS version of the jQuery code would be this

document.addEventListener("DOMContentLoaded", function() {
  console.log("Hello World");
});

I just prefer the jQuery version because it implements by itself some fallbacks related to browser compatibility, and it also runs the code immediately if the site is already loaded (compared to the code above that doesn’t run if you run it from the console after the page has already loaded)

ok, as I have mentioned I have wrapped code in listener DOMContentLoaded in one test to make sure all elements are in DOM but it did’n worked for me. I usually use this listener only for testing in Embed where it make sense but JS in page settings should run after DOM is rendered including dynamically added elements and DOMContentLoaded should be redundant (obviously this is not the case true).

I can also use slides and aria to achieve same effect without trouble but it is more code and I have tried to play with dots.

Now I know that I should in special cases (working with dynamic elements ) add my functionality into functions queue. :wink:

1 Like