Replies: 1 comment 3 replies
-
|
Hi @ehenighan, sorry for the delay in responding here. If I understand your fundamental issue, it seems like you are trying to create loading screens that act as sort of a "skeleton" of the content to be loaded, with a header and footer. Meaning you have many possible variants of the loading screen based on where the user wants to navigate to. Is that a fair assessment? I'm asking about this because we are generally considering if there are better patterns for dealing with this. For example, one solution may be to prefetch the expected content to eliminate the need for a loading screen. Or cache certain screens that can be re-used as loading states across the app. Still considering the best option here, more info on your use case would help. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, no problem whatsoever on the delay! Everyone's busy :) This was just something that occurred to me while digging through layers of the bottom nav bar problem and seeing various types of rendering issue. I was looking at the show-during-load and hide-during-load options and just thinking 'these are more tightly restricted than they need to be'. So I figured that one easy approach to neat screen transitions would be to allow those two attributes to preserve a copy of the current screen through the new page load, and declaratively hide arbitrary sections of the page with a list of IDs - and then you could get the nice bottom-bar behaviour easily without the extra pain of that shared rendering component, simply by reusing the current screen during loading and hiding everything apart from the skeleton, so you can dynamically/arbitrarily skeletonise the current page during transitions - even to the extent of transitions to different pages preserving different elements. I don't think it's super useful now you guys have solved your nav bar problems but it seemed like an easy change to make - just removing some restrictions - and it could unlock some cool UI transitions in the hands of a better developer than me 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I see what you're suggesting now. Definitely could work if the current and next screen share many attributes. I've been thinking along similar lines about potentially preserving elements across screens, or even transitioning them (see https://reactnavigation.org/docs/shared-element-transitions/). It's probably too early to make any changes here without thinking more about it. Just in case you weren't aware, you can also override the default loading screen (spinner in the middle of the page) with a custom React Native component. Now this won't be controlled from the server via XML, but it does give you more control and a loading screen that is built into the client (no need to shove extra screens in your response). I was thinking of experimenting here with an implementation that renders XML that is cached in the client, to find a balance between server-provided rendering, instant-rendering of the loading screen, and shipping less XML in standard responses. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that sort of transition is what I was (eventually) thinking about but initially just by hooking into the existing attributes in a simpler way without too much extra complexity with animation. The nice thing about an ID list in the attribute is that it can vary depending on the source/destination screen pair so it's customisable per link/action for when the screens share more or fewer elements. Not sure if it's worth mentioning here as a related idea but the Idiomorph DOM-merging model might help with this as well - or otherwise might be a nice way of merging replacement fragments into a screen: https://github.com/bigskysoftware/idiomorph |
Beta Was this translation helpful? Give feedback.
-
Span out from a comment in an issue ticket:
#956 (comment)
I go into more detail below than I originally expected about why I'm suggesting this change so I'll put the suggestion first:
show-during-loadfor a navigation action, instead of only allowing one ID in the attribute for a single screen, allow more if the first ID in the attribute is the current screen and then evaluate the remaining IDs against the copied screen contentshow-during-loadis/starts with the current screen ID as above, instead of ignoringhide-during-loadevaluate the IDs to be hidden against the copied screen contentContext:
I was trying to preserve the tab navigation bar at the bottom of my screen during tab loads/transitions, as well as the header. Due to some problems displaying the
<header>element as a child of the<screen>the header is actually just a top-pinned<view>element inside the<body>but hopefully that doesn't really affect this discussion.I ideally didn't want to create n loading screens for each of my tabs because for other reasons our styling model is to create a colour palette and then decompose the available styling options into lots of utility classes in the Bootstrap 5/Tailwind style, so unless we break that model to extract specific styles just for header & footer items we'd have to copy a lot of style tags into the loading screens and it would become a bit bloated and unwieldy. There are other reasons as well but hopefully you get the idea.
What I planned to do was to structure a single screen broadly like this:
On selecting a tab navigation option, my plan was to have these behaviours:
show-during-load= the current screen ID, to preserve the UIhide-during-load=screen-body-contentBecause you can only target a screen with
show-during-loadduring a navigation action, I tried putting the navigation behaviour itself ondelay="1"and before that had a separate immediate behaviour to show the spinner, with an 'on-load once' behaviour to ensure it got hidden again if you navigated back to the tab.The spinner bit worked, but I didn't realise that
hide-during-loadwas ignored for navigations because it presumes the whole parent screen is going away (https://hyperview.org/docs/reference_behavior_attributes#navigation-actions-2) - so the main body content just got bumped down and stayed visible.If the pair of suggestions I made at the start were in place, I'd have been able to just have a single standard behaviour with:
show-during-loadas the current screen ID and the spinner IDhide-during-loadasscreen-body-contentThen I'd be able to preserve arbitrary UI elements from the current screen while hiding others and showing a loading indicator, until the new screen was available. In my case I'd preserve just the header and footer but it would potentially unlock some nice UI where without any complicated screen juggling and style duplication, you could have anything you wanted from any given page pinned through a screen transition.
Beta Was this translation helpful? Give feedback.
All reactions