Can this library function without being in charge of rendering the views being navigated to?

[jgarplind]

I have a non-standard use case, for gradual adoption. Given a web app, I would like to be able to piece by piece turn it into a React Native app. The first stop would be to render the whole web app in a WebView, and this is not a problem.

Secondly, I was thinking of adding native navigation, but having the route definitions remain in the web app. The way I would like for this to work is if I could have access to onIndexChange (to send navigation messages to the web app) without having to render a view, since the WebView would be a sibling component to the TabView.

I played around a bit with this yesterday, and found that it was difficult to "hack around" the sane defaults of this library, obviously not built for this use case. I found that renderScene is required, and tried to find ways around that. I tried to pass the SceneMap an empty object, to give it () => null for a component, etc. This works fairly well, if not for one thing: Half the screen goes black. I think this is because of style={styles.fullWidth} setting height: '100%', since by wrapping the <TabView> in my own <View> and setting a reasonable height (80 in my case) the visual issue goes away.

However, it goes without saying that hard-coding a value like that is not a great look, and it could break in thousands of ways.

So, I would just like to ask if anyone can think of a robust way to accomodate such a use case, or if I'm better off not attempting this until the app can offer meaningful scenes as opposed to a sibling WebView.

[okwasniewski]

Hey,

Unfortunately, this library is intended to manage views by itself. The easiest way to make it work nicely would be to render new webview (one for each tab) and let this library manage its state. Honestly, I'm surprised this hack worked can you share a screenshot? 😅

[jgarplind]

Understandable, thanks for confirming.

I did the one WebView per tab, but the initialization cost is significant enough that it detracts quite a bit from the user experience.

Sure, I'll share some details next time I have it running.

[okwasniewski]

As a workaround you can disable lazy loading, this would load all the tabs at once and give users a better experience but would also slow down the initial load.

[jgarplind]

As a workaround you can disable lazy loading, this would load all the tabs at once and give users a better experience but would also slow down the initial load.

I tried this in two versions, neither of which performed satisfactory. Sharing details for others on similar endeavors, not because I expect a solution:

1. One WebView per endpoint, so one WebView would load https://example.com/articles, the next one would load https://example.com/albums, etc. This might work in some scenarios, but for me, there is too much initialization going on within the WebView, so even disabling lazy loading, there is still auth etc. that needs to be resolved for every navigation, even when navigating back to a view I previously visited. If I lift the auth state to the native app, that could change the situation.
2. My first attempt was just to set 4 identical WebViews, one for each scene. This actually performs a lot better for some reason (maybe the same WebView is reused under the hood?) but the navigation (driven by passing messages to the web app) was not fully reflected to the user (the behavior was odd but consistent. Combination of hackiness and need for a further deep dive to understand the mechanisms at play lead me to stop here.

[jgarplind]

Honestly, I'm surprised this hack worked can you share a screenshot? 😅

Looks like this:

Setup:

<>
  <WebView />
  <FourTabs />
</>

Inside FourTabs:

<TabView
  ...
  renderScene={SceneMap({})}
/>