Open kiraarghy opened 4 years ago
Hey! Thanks for starting work on looking into live reloading, I think it's something we'd all definitely love to have. I haven't self engineered any live reloading processes before, so I decided it was best to hold off until someone with some experience with it came - and thus here we are!
I cloned your WIP and while its cool to see it can rebuild pretty fast, I'm thinking the idea of the first approach could work better, where it never has to entirely kill the server and can rebuild just the parts of the app that change. Especially if someone was working with a large amount of data this would make reloading super quick. (maybe with an npm run dev we can keep the graphql server running the entire time on a different host, saving time on restarting the graphql server and letting devs test it with graphiql)
Picking up changes in the data layer is super helpful though too, so maybe we could use something like your WIP just on changes to jungle.config.js
?
Your work looks great happy to see you started working on this ๐๐
Thanks for the direction, I'll have a look into it this week!
Thanks for the direction, I'll have a look into it this week!
Actually spent some time last night working on something similar to option 1, where it only rebuilds the route that changes etc... it's in the branch feature-live-reloading
It has a bunch of stuff missing tho, so I highlighted them each with a //TODO
in the code
Oh, I just saw your reply @ConProgramming, your branch seems slightly further along in development so happy to go with that!
Can I help out with it at all?
onRouteUpdate
(not sure how to do this best, thinking you just move over your code you already did for browser refresh?)These are the todos rn and my thoughts on them, I think those four and we should be good for live reloading!
Great, I'll pick up the refresh page, and maybe have a look at the onRouteUpdate event if I have time tomorrow.
I have a more 'production(y)' svelte webpage I'd love to rearchitect on JungleJS but I'm hesitant to move onto it till the developer experience is there as I'm not the only contributor. I think live reloading would give me that impetus to move so I'm excited for it to get released! ๐ฅณ
Awesome! I'll look into fixing the npm run build and then rebuilding routes that rely on components/static files ๐
Added a working npm run build
with https://github.com/junglejs/junglejs/commit/e868f00e80ac7198e648bb588154ee997ec4d8da
Did Do something for onRouteUpdate event "unlink" (thinking I can just delete the folder or file that is in build) and Refresh page in onRouteUpdate (not sure how to do this best, thinking you just move over your code you already did for browser refresh?) with https://github.com/junglejs/junglejs/commit/23212647dcae2a138dd8567bc645f8fc3d4e7dcc
@ConProgramming can we merge to master?
@ConProgramming can we merge to master?
Yes... but first we'd preferably want to do "Rebuild routes that rely on components or static files" from the todo list above and then test all this on Windows.
We'd also probably want to write up a blog post on the changes and how to migrate etc.
I'd love to bump this and help in any way I can, would love to help with the blog post!
I'd love to bump this and help in any way I can, would love to help with the blog post!
I think the last important thing we need here is using dependency maps from rollup to somehow efficiently rebuild pages when the components they depend on change. I just honestly haven't yet had the time to look into this... if someone else were to take a look that'd be awesome tho!
Or maybe we look into using Vite or esbuild or smthn instead of rollup lol... the stuff Vitepress is doing is interesting!
Hey Conner and others,
I'm having a look at live reloading for JungleJS and I would be interested in some soundboarding.
From what I understand I can see two approaches (but my experiences of live reloading is pretty limited):
We listen for changes in files using chokidarwhen changes happen we can rebuild using a function similar to the readRoutes function and then trigger a page refresh.
We listen for changes in files again using chokidar and then blow away the current server, and do a full rebuild including our data sources, similar to my WIP here and again trigger a page refresh.
Option 1 has some advantages in that it will be quicker and more seamless, but it wouldn't update if there were any changes to our GQL data layer.
Option 2 has the advantage of picking up any changes in our data layer and would require minimal changes to the core jungle js code as it could be orchestrated by a simple script similar to the current app.js script in the template repo.
Would be interested in views on this before I continue with my work ๐.
Thanks.