Open ansarizafar opened 1 year ago
He mentioned routing in the documentation, as I imagine client-side routing might increase the library quite a bit 😊
Router is a key part of a web application. It can be build separately and not as part of core library or an adapter for TankStack router TanStack/router
Personally i'd be interested in using Remix router with ArrowJS at some point — something akin to what @brophdawg11 has been doing with https://github.com/brophdawg11/remix-routers and vue/svelte
For the foreseeable future this will be considered out of scope.
This has been tickling the back of my brain for a little while. The basic wire up is pretty straightforward given Arrow's reactivity. The "tricky" part not handled by the @remix-run/router
(and this is true for react-router
/remix-router-vue
, etc.) is handling the nested routing via an <Outlet />
component so you can render nested routes based on router.state.matches
. This then opens up route-scoped useLoaderData()
capabilities as well.
Ignoring nested routes though, a simple non-nested UI with Link
/Form
support clocks in at just over 100 lines including console logs for clarity 😀: https://codesandbox.io/s/remix-router-arrow-js-ncu52c?file=/src/index.js
I guess its time to build an entire meta framework now 😂
Not like you don't have enough else to do 😂 ! If you ever dip into SSR don't forget to check out createStaticHandler
from @remix-run/router
as well. Docs are still pending but it'll handle all the server-side data loading aspects for you.
Nice contribution @brophdawg11 ! I'd been looking at a (now archived but still good) routing solution "roadtrip" - which is actually a strong fit for driving view from state with arrow-js. But, as you've shown, the @remix-run stuff is very interesting too....ahhh dilemmas!!
I've been having fun experimenting with Remix router wrappers for Lit and Preact Signals recently and would love to help with a wrapper for Arrow too! As @brophdawg11 mentioned, to properly handle nested routing (and make some other APIs nicer to use), Arrow will need a context system.
I’ve actually been thinking about how context could be created in as minimal of a way as possible — nothing to report yet 😂 but I’m open to suggestions. It’s certainly possible for each template to pass it’s parent’s context down via internal call states, but I really want to avoid creating an implicit tree that requires an arrow template as an ancestor. For example, in a perfect world you could:
<dom-element>
{ arrow-template }
<another-dom-element-not-rendered-by-arrow>
{ arrow-template } <!-- this guy could read context -->
</another-dom-element-not-rendered-by-arrow>
{/ arrow-template }
</dom-element>
The above example assumes that <another-dom-element-not-rendered-by-arrow>
is a dom element created by some outside force, lets say someone dropped a chunk of old jQuery code right in there, but then a child of that could still pickup context. Crawling parent nodes is horribly inefficient to be a framework feature though and rendering sequencing cannot be guaranteed in this scenario either so an index-based store wouldn’t work. Sounds like a fun problem honestly. More to think on here.
I have two ideas here:
Arrow looks promising. Is there any plan to build a client side router or an adapter for TankStack router TanStack/router ?