framesurge
Add capsules system
This is a more ambitious feature, but I think it's doable! I want Perseus to be able to re-render only parts of content, say, keeping a sidebar and a header around while other content changes. The system to do this is too complex to explain here, but I'll publish a formalized document of how it will work soon.
The central idea is that a page should be able to have a structure like Header -> Sidebar -> Content, and each new Content shouldn't trigger a re-render of Header and Sidebar. Moving to a new Sidebar equally shouldn't re-render the Header.
I don't think this will make it to v0.2.0, but it'll be ready for v0.3.0 when that's released. Note that metadata modification will be included in v0.2.0 though.
Given that static exporting is going to take us to v0.3.0, this won't be included until v0.4.0 (or maybe later).
I'm also looking forward to this. that's who a real SPA application supposed to render pages with the help of DOM Diffing or VDOM.
Okay, this will be worked on for v0.4.0 along with engines (tracked by #59). That's going to be a very big release!
Alright, I've designed this up to the final part, which is removing the smallest part of the DOM possible to go from one page state to the next (which is reasonably complex). With the current idea, network requests would be reduced, but I still have a bit more design to do. Nonetheless, this will definitely ship in v0.4.0, and I'll aim to support proc macros that can turn any Sycamore component into an island (capsule, island, terminology is still in flux), which would slow down builds, but allow very aggressive optimization of rendering.
I'm seeing the tremendous work you've been doing, 1000s Kudos, I did few readings, I will keep you update with the new developments
Thank you very much! Yeah, if you have any ideas for this, please let me know!
Okay, if we use the shadow DOM for this (and hope that Sycamore can manage that), we're good! The only two problems now (again, this is all in theory still) are to do with the ergonomics of having to wrap every island in Island() and having to declare the islands that a template (or another island) uses. The latter is the priority for me, I want to be able to avoid that. We need a way to get all the islands being used in the app somehow, and the current design has each template declare its dependencies. There should be a more ergonomic way to do this, I'll have a think about it.
Okay, with the changes in #223 and the renaming of the #[template_rx] macro, which basically 'stabilizes' Perseus' reactive state platform in my eyes, I'm going to (finally) start work on this!
I don't expect a shadow DOM system to make it to v0.4.0, but I reckon the basics of this system definitely will. (Though dependency declaration will likely be a persistent issue for a while.)
Alright, somewhat incredibly, this system is complex enough that basically anything that impacts the build process in any way whatsoever blocks it. I'm going to prioritize #150 and #221 before tackling the weeds of this, though there is a basis in my local branch now. I fully intend to release v0.4.0 by the end of November (saying this here to hold myself accountable!), most certainly with some sort of capsules system! (It won't be half-baked, don't worry, I intend for this to work properly and effectively with the new state platform and the improved build system.)
Alright, after over a year now, this has finally been merged! I'm satisfied that capsules are basically feature-complete for now, and v0.4.0 will follow very closely on the heels of this. There are a few tiny little things I want to clean up, and then v0.4.0-rc.1 should be ready!
Also, as a brief update on the shadow DOM system: right now, it is completely unnecessary. The Perseus capsules system allows developers to split pages up into atomic units that can be independently loaded, cached, and preloaded through the state store, which can store an arbitrary number of pages and widgets in memory. These can then be all frozen for immediate thawing. WebAssembly is fast enough that a shadow DOM layer is just not needed. Also, widget properties make this very complex to implement (since a widget can be used in different ways in different places).