I just used a Webflow layout in a Meteor app, which handles packaging up all the bits to be sent to the client and shipping them down. Instead of manually defining <link rel="stylesheet" ...>, Meteor minifies everything, sends it to the browser, and evaluates it for you.
One quirk that comes as a result is that you no longer control load order of resources by where in the document they appear. You can control the load order by naming / structuring your app such that Meteor will minify things in whatever order you want, but you are encouraged to make sure resources can be loaded in any order instead.
So, to the point: Iāve discovered that the load order of webflow.css and .webflow.css is actually significant. That was a bit of a surprise, since I learned the hard way years ago about CSSā āspecificityā rules. I guess both files contain equally-specific rules.
Would love to know if Iām wrong about this - but otherwise itād be a nice (albeit low priority) thing to fix.
@thunder After looking through the Meteor docs, you are correct- the CSS files are being loaded in a different order than one might expect.
Meteor outlines their rules for this behavior as follows:
The JavaScript and CSS files in an application are loaded according to these rules:
Files in subdirectories are loaded before files in parent directories, so that files in the deepest subdirectory are loaded first, and files in the root directory are loaded last.
Within a directory, files are loaded in alphabetical order by filename.
After sorting as described above, all files under directories named lib are moved before everything else (preserving their order).
Finally, all files that match main.* are moved after everything else (preserving their order).
Based on the above, I would recommend that you move the two library CSS files into a subdirectory named lib, so that your new file structure looks like this:
Thanks so much for the help. I have it working, it is indeed easy to restructure the project files to affect the load order.
What I was trying to point out, though, is that it was surprising. So if itās not feasible to write the rules differently so they are commutative, then perhaps a bit of documentation with a link from the code export window? Again, low priority, just thinking to save future users from the surprise.
Thanks again! Maybe Iāll write something up about using Webflow + Meteor. Itās great so far, only thing I havenāt gotten working is the js interactions (no big surprise there, Iāll just reimplement them I guess).
I think I have a hunch what might be going on with the front-end JS as well.
Since Meteor is essentially a single-page app, you would need a way to re-trigger the webflow.js āreadyā event on all the modules, each time the virtual routes change.
We do have a fix for this in the worksā¦ let me see what I can do about getting it merged into production for you
Btw, on load order - I found another method that I like: meteor packages. Itās possible to define a small āpackageā with a js file that describes itās runtime load order/dependencies, and other stuff. Very clean solution, meteor makes sure things will be shipped to the client in the right order. Iāll publish my solution as an example for others to copy.
Hi @thunder, we pushed an update to webflow.js which improves support for single-page apps.
Whenever you are rendering a page that contains webflow components (slider, navbar, etc), you will need to initialize them. On typical sites, this happens in the jQuery.ready handler. However, in single-page apps the HTML is being built dynamically.
Weāve added a method to manually invoke the ready handler on all components. This should be called after your HTML is inserted into the document.
Webflow.ready();
Once the elements are initialized they should behave as they normally would in a webflow site.
Just before the route changes in your app, you will want to prevent those components from updating. You can do this by calling the destroy method.
Webflow.destroy();
Once the route has changed, you can call ready() again, and the cycle starts anew.
Hopefully this makes sense! Good luck with your meteor app.
Iām writing at the moment my own chat tool and Iām really interested in your experiences with the combination of webflow and meteor. How you handle the changes if you have translated the code to templates. Iām not sure at the moment to use this combination. Could you use the animations ? is the generated code quality good enough for further maintenance ? Iām look forward to get an answer. Thanks
I used it for a while for a little project, but have put that on ice - so I donāt use it anymore. My other projects are simpler, so I just host the flat files with almost no server-side component at all.
My $.02 - it was possible to make things work, but a little finnicky. I didnāt get animations working (but I didnāt try hard / care much for that project). Overall, I do not recommend itā¦ though I donāt have any great alternatives. If you do want to make this kind of a setup work, my āsite-updateā tool may help you:
I no londer use it either, but it should work. I wrote it for this purpose.
Thank you very much for your answer. I have checked your site-update tool and its look really nice. I will try to move forward with web-flow because I think for the first layout it will save me time.
I hope I get the animations running. Perhaps with the webflow.ready method after rendering.
If not will open a case in the forum.
Perhaps it is possible to trigger then manually?
I didnāt end up using that combination, and didnāt have the time to write about it.
You can integrate them, and the site-update tool I wrote (see above) helps to make it repeatable, but it takes too long / is too much work to do the integration that way. In the end, I think youāll be better off either choosing between webflow/meteor, or resigning yourself to prototype in Webflow and integrate changes into Meteor by hand. Keeping some documentation will help you there in case you donāt touch a project for months or have multiple people involved.
