First of all, great video! Thank you for your support in the community. Quick question (a bit off-topic..): I saw that in your video, when you selected your "section hero" component, your properties panel had pre-defined tags like "light" "dark" "inverted", etc. directly under the text input field. How did you do that? And how does it work?
Thanks so much! I created a Chrome Extension that adds those component buttons based on different values in our embed. This tutorial shows how it works and how to set it up. th-cam.com/video/o4yqHL4b904/w-d-xo.htmlsi=qQyMlYKgC5bjLW5Q&t=59
Love this! Feels a bit like using a js framework where all html, css and js is grouped per component. One question though: if I’m using Barba js for page transitions, would this still work for components that aren’t on the homepage? Since you’re never actually reloading the page when changing pages.
Thank you! You're right that this wouldn't work with Barba.js as is. We would need to remove all functions from pageFunctions before the new container enters and then execute functions after the new container enters like this. timothyricks.notion.site/Page-Functions-With-Barba-js-948df85dca2f4a399e98c32e0ec5ea79?pvs=4
Are there times it makes sense to send an email notifications when there's a serious code error, or is just better to wait and let it be broken until someone flags. Sometimes as new pages are stood up, things can miss QA.
All the years and current best practices have taught that tags with regular HTML content should be avoided. Every time the browser encounters a tag, the parsing of the HTML is interrupted, regardless of whether the script is inline or external, read-only or executed. I feel for you Timothy, finding a solution to load scripts only when the appropriate elements are present, but I don't think that's the solution. Much respect to you! 🤝
Thank you, Dennis! I just added defer to each script tag so DOM Parsing is not blocked. It's similar to including script tags in the head with defer set.
Unfortunately, this is ignored by browsers at this point. The defer attribute only works for scripts whose content is loaded via src="", not for inline scripts. 😬
@@denniskarg Oh, I see! Thank you! Would the next best thing be a DOMContentLoaded so that the everything inside the script isn't parsed until the DOM renders?
Unfortunately no, that wouldn't help. The problem lies with the tag itself, regardless of what it contains. If possible, load external scripts in the with the defer attribute and always place inline scripts in the before . What you want to achieve is more likely to work with JavaScript modules to load scripts, for example, if case XYZ applies (e.g. element present on the page). However, this is not something that can be done just like that and I would only recommend it if performance needs to be improved if it turns out to be a problem.
@@denniskarg Thank you for all the really helpful feedback! I might store each embed in a component separate from its section so that embeds can be added at the very bottom of the body, letting all html get parsed first. If we were to store all scripts externally, then we could dynamically load in scripts based on the sections used on that page. But if it's at all possible, keeping the scripts in Webflow seems like the best solution. This is a problem that really needs to be solved before Page Building mode is released, and this solution is the best I found so far for solving it.
Hi Tim! Sorry for all my questions lately. I'm trying to transition from your old tutorial on swiper.js to this component nested method and I can't get it to work properly. I'm wondering if this has to do with Swiper updating to V11 from V8 or maybe I'm not properly copying and pasting the script from the page's body tag into the component embed? I also have the CSS linked in the head tag of the page still?
All good! Yes, the css should still be in the site settings head code The swiper js link should be the first line of code in the site settings footer code. I would check for console errors just in case some code isn’t being added correctly in the embed.
@@timothyricks I was having the same issues. But the error I was specifically getting was "*Error executing function landerIntro: ReferenceError: Swiper is not defined". I double checked: Swiper CDN before my function (based off your newest JS in component video)
Timothy this is unreal, excellent thinking here.
Thanks so much!
Wow. Not even 24 hours this was the exact problem I was having. You’re a absolute superhero
It keeps getting better and better. 🎉
Thank you!!
So helpful! Thanks!
Beautiful. I tried to make this work a while back, but gave up after the duplication problem.
Thank you! The load order part was the tricky part for me.
First of all, great video! Thank you for your support in the community.
Quick question (a bit off-topic..):
I saw that in your video, when you selected your "section hero" component, your properties panel had pre-defined tags like "light" "dark" "inverted", etc. directly under the text input field. How did you do that? And how does it work?
Thanks so much! I created a Chrome Extension that adds those component buttons based on different values in our embed. This tutorial shows how it works and how to set it up.
th-cam.com/video/o4yqHL4b904/w-d-xo.htmlsi=qQyMlYKgC5bjLW5Q&t=59
@@timothyricks Oh wow, that sounds nice! I'll check it out.
Thank you!! :)
Love this! Feels a bit like using a js framework where all html, css and js is grouped per component. One question though: if I’m using Barba js for page transitions, would this still work for components that aren’t on the homepage? Since you’re never actually reloading the page when changing pages.
Thank you! You're right that this wouldn't work with Barba.js as is. We would need to remove all functions from pageFunctions before the new container enters and then execute functions after the new container enters like this.
timothyricks.notion.site/Page-Functions-With-Barba-js-948df85dca2f4a399e98c32e0ec5ea79?pvs=4
Can't thank you enough! Using an IIFE to add this function to the window object is actually ingenious!!
Are there times it makes sense to send an email notifications when there's a serious code error, or is just better to wait and let it be broken until someone flags. Sometimes as new pages are stood up, things can miss QA.
That could be a helpful feature! I'm just not sure yet how we would prevent the email from sending for each user that visits the site.
All the years and current best practices have taught that tags with regular HTML content should be avoided. Every time the browser encounters a tag, the parsing of the HTML is interrupted, regardless of whether the script is inline or external, read-only or executed.
I feel for you Timothy, finding a solution to load scripts only when the appropriate elements are present, but I don't think that's the solution. Much respect to you! 🤝
Thank you, Dennis! I just added defer to each script tag so DOM Parsing is not blocked. It's similar to including script tags in the head with defer set.
Unfortunately, this is ignored by browsers at this point. The defer attribute only works for scripts whose content is loaded via src="", not for inline scripts. 😬
@@denniskarg Oh, I see! Thank you! Would the next best thing be a DOMContentLoaded so that the everything inside the script isn't parsed until the DOM renders?
Unfortunately no, that wouldn't help. The problem lies with the tag itself, regardless of what it contains.
If possible, load external scripts in the with the defer attribute and always place inline scripts in the before .
What you want to achieve is more likely to work with JavaScript modules to load scripts, for example, if case XYZ applies (e.g. element present on the page). However, this is not something that can be done just like that and I would only recommend it if performance needs to be improved if it turns out to be a problem.
@@denniskarg Thank you for all the really helpful feedback! I might store each embed in a component separate from its section so that embeds can be added at the very bottom of the body, letting all html get parsed first.
If we were to store all scripts externally, then we could dynamically load in scripts based on the sections used on that page. But if it's at all possible, keeping the scripts in Webflow seems like the best solution. This is a problem that really needs to be solved before Page Building mode is released, and this solution is the best I found so far for solving it.
Hi Tim! Sorry for all my questions lately.
I'm trying to transition from your old tutorial on swiper.js to this component nested method and I can't get it to work properly.
I'm wondering if this has to do with Swiper updating to V11 from V8 or maybe I'm not properly copying and pasting the script from the page's body tag into the component embed? I also have the CSS linked in the head tag of the page still?
All good! Yes, the css should still be in the site settings head code The swiper js link should be the first line of code in the site settings footer code. I would check for console errors just in case some code isn’t being added correctly in the embed.
@@timothyricks I was having the same issues. But the error I was specifically getting was "*Error executing function landerIntro: ReferenceError: Swiper is not defined". I double checked: Swiper CDN before my function (based off your newest JS in component video)
Hi Timothy, which of your videos would you recommend I watch to learn the Lumos framework? It seems a bit confusing
Hi Edan, I just released a crash course for learning Lumos here. th-cam.com/play/PLoXSZEwtbyStInsfWsEO5ouJ7HTfMMLeA.html&si=6J0pGYXLJNGZs0qn
Nice!
If the library scripts are defered, would it work? :)
Tried it, as expected that doesn't work.