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

Routing in lively.next #1479

Open
linusha opened this issue May 6, 2024 · 2 comments
Open

Routing in lively.next #1479

linusha opened this issue May 6, 2024 · 2 comments
Assignees
Labels
📚 documentation Improvements or additions to documentation ✨ enhancement New feature or request 💬 ideas welcome For feature ideas where more input on design decisions and conrete direction are warranted.

Comments

@linusha
Copy link
Contributor

linusha commented May 6, 2024

This is more of a brain dump as of now, as I do not have a good solution to the problem yet. However, the following is something I want to continuously think about while working on the relaunch of the lively web page:

When building static websites, as opposed to truly interactive applications, one needs the capability to route between different URLs. The two most important benefits this brings is that

  1. It is possible to link to specific places on the site.
  2. One can use the browsers "back" button in the expected way.

For SPAs such as lively applications, the easiest and most flexible way of doing is by using hash routing.

The current way I implement this in the website is by instantiating multiple HashRouter instances (a class I implemented inside of the website project) which manage different prefixes of the page (e.g., there is a router solely responsible for all things under the /blog prefix). Then, I write specific bindings for every UI elements that should route somewhere.

The question this bags is twofold:

  1. Can we streamline this to provide an easily pluggable solution so that not every page needs to write all this boilerplate code?
  2. In the case that we cannot do 1, what is the cleanest way to order this boilerplate code, so that we can provide a passable "cook book" for this problem.
@linusha linusha added 📚 documentation Improvements or additions to documentation ✨ enhancement New feature or request 💬 ideas welcome For feature ideas where more input on design decisions and conrete direction are warranted. labels May 6, 2024
@linusha linusha self-assigned this May 6, 2024
@merryman
Copy link
Member

Once the basic implementation of the router is in place we can make it easily accessible via a custom ViewModel class that can then be parametrized like so:

const Webpage = component({
   defaultViewModel: RouterSubclass,
   viewModel: {
      'home': LandingPage,
      'about': AboutPage,
      'contact': ContactPage,
   }
  // ...
}); 

The Router- viewModel will then internally take care of any layout applications, component loads or swapping the morphs in response to navigation and url requests.

@merryman
Copy link
Member

merryman commented May 10, 2024

Another idea is to further supply the Router with fine grained state information about the components themselves.
For instance we could store away the scroll information and some other custom viewModel property automatically in the router to reconstruct the state of a page more correctly, by wrapping the property values with a track() function.

  const AboutPage = component({
     defaultViewModel: AboutPageModel,
     viewModel: {
         selectedSlideNumber: track(0)
     },
     submorphs: [
        {
           name: 'scroll wrapper',
           scroll: track(pt(0,0)),
          submorphs: [
            // ...
          ]
        }
     ]
  });

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📚 documentation Improvements or additions to documentation ✨ enhancement New feature or request 💬 ideas welcome For feature ideas where more input on design decisions and conrete direction are warranted.
Projects
None yet
Development

No branches or pull requests

2 participants