-
Notifications
You must be signed in to change notification settings - Fork 135
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
bookmarkable URLs for UI state #202
Labels
Comments
scottlamb
added a commit
that referenced
this issue
Mar 7, 2022
This structure (described in #202 (comment)) has less activity-specific logic in App.tsx itself and avoids duplicate route handling. This fixes the `No routes matched location "/"` mentioned in #202.
scottlamb
added a commit
that referenced
this issue
Mar 7, 2022
I haven't figured out how to expose its state in the URL (for #202), but documenting how it works today seems like a good first step.
scottlamb
added
javascript
Pull requests that update Javascript code
and removed
js
labels
Sep 30, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@krystaDev in #193 started adding bookmarkable URLs for UI state: you can bookmark a live view URL that specifies the layout and cameras. In 782eb2f I extended it so that some of the list view options are bookmarkable.
Three things I'd like to fix/add before calling this feature done:
No routes matched location "/"
. I think the problem is simple: theRoutes
element is in the document here but empty.TimerangeSelector
is...intricate. It keeps a bunch of state together in one property that is mutated with this reducer. Some of it goes into the URL (the current selected date(s) and times, the single/multi day selection toggle). Some of it shouldn't (the clickable days, which is derived from state returned from the server). I'm not sure how best to structure the code.I wonder if 1 and 2 are symptoms of a pre-existing bad code structure in
App.tsx
. Part ofLive
's state, the selected layout, is inApp.tsx
so that it can be selected in the top menu and used in the main pane. It already smelled a little funny to have part of the activity's implementation inApp.tsx
. And now with routes this meansApp.tsx
kind of does the routing twice (here and here), which will get worse as we add more activities. I think I can restructure it so that we have aMoonfireFrame
component with the overall layout (passing inactivityMenuPart
andmainComponent
). Once logged in, we render a<Routes>
to choose the activity with less activity-specific structure inApp.tsx
. And then each activity can use the frame component and be fully responsible for its own state and menu piece.The text was updated successfully, but these errors were encountered: