Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client side router #3

Open
ansarizafar opened this issue Nov 18, 2022 · 11 comments
Open

Client side router #3

ansarizafar opened this issue Nov 18, 2022 · 11 comments

Comments

@ansarizafar
Copy link

Arrow looks promising. Is there any plan to build a client side router or an adapter for TankStack router TanStack/router ?

@sifferhans
Copy link

He mentioned routing in the documentation, as I imagine client-side routing might increase the library quite a bit 😊

@ansarizafar
Copy link
Author

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

@justin-schroeder
Copy link
Owner

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

@justin-schroeder
Copy link
Owner

For the foreseeable future this will be considered out of scope.

@brophdawg11
Copy link

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

@justin-schroeder
Copy link
Owner

I guess its time to build an entire meta framework now 😂

@brophdawg11
Copy link

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.

@andymans
Copy link

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!!

@markmals
Copy link

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.

@justin-schroeder
Copy link
Owner

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.

@markmals
Copy link

I have two ideas here:

  1. Use custom elements/web components: there is an open standard protocol for cross-framework web component context using event listeners attached to the custom element. You could create custom elements to handle context in a generic way and then wrap them with a more Arrow-friendly function component syntax. This works particularly well for context compatibility across the DOM tree rather than relying on a home-built system, but it does mean adding extra elements to the DOM, which might be okay in some cases but is definitely not in others. I'll experiment with this some this week in relation to the router.
  2. Use the reactive system: Voby does something interesting here: their context system is part of their reactive system (Oby), not their component/templating system. It's built in a way that any code running within a reactive root can access the context, so this might work well for the sort of jQuery-within-an-Arrow-template scenario, but less well with custom elements, which are instantiated by the browser and managed outside of your control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants