@equinor/mad-screens

[tormodAase]

Hey guys, I wanted to start a thread for discussing mad-screens.

As you all know, we have a goal of getting rid of mad-expo-core, and replacing it with smaller packages. One of the most important features of mad-expo-core is it's screens (login, onboarding, feedback, settings, etc.), and in our current discussions around the office, we wanted to extract those screens into a package called mad-screens. I personally had a goal of creating some kind of mad-navigation instead, but I don't think that will be a great solution now that expo-router is on the rise. My plan for mad-navigation wouldn't work in a file-based routing system.

So assuming we create a mad-screens package, do you have any suggestions for what to put into that package?

Here are some things I've been thinking about:

• authentication is closely related to the login screen. Should we export authenticateSilently from mad-screens?
• demo mode is closely related to the login screen. Should mad-screens be in charge of keeping the 'state' of demo mode?
• language is commonly set in the onboarding screen. Should mad-screens be in charge of keeping the 'state' of selected language?

Please comment if you have any comments regarding the above questions, or if you have any other ideas for this package!

[HavardNot]

I guess mad-screens would need mad-components as a dependency, so I think mad-utilities should be the second dependency of mad-screens where the logic not related to rendering is located. Demo mode, authentication, API calls, state handling of user configurations, are all examples of non-rendering functionality that is commonly used by both mad-expo-core screens and app-specific ones.

I think mad-screens should be as purely JSX as possible and simply provide the boilerplate screens for our apps the way we use them today.

This is just the opinion of a newbie

[tormodAase]

The problem with letting the apps be in charge of demo mode and language, is that we would end up copying code between apps. In my opinion it would be better to have getIsDemoMode and getSelectedLanguage exported from one of our packages. I also believe screens should be as easy to set up as possible, with as little config as possible. That way we can make sure things behave the same way regardless of which app we are working on.

[HavardNot]

To clarify, I dont think the apps should be in charge of implementing generic functionality such as demo mode and language. But rather that these functionalities are available from a third-party library (e.g. mad-utilities)
Mad-screens will depend on mad-utilities for the generic applicants such as login demo button, select language in onboarding,
Meanwhile, if you need to access isDemoMode and getLanguage in an app-specific screen, these would be imported from mad-utilities instead of mad-screens.

Again, I am a newb and have no idea what im talking about

[tormodAase]

Yeah that kinda makes sense!

[HaakonSvane]

I'm all for separating concerns as has been mentioned here. Should a screen package be responsible for exposing demo mode functionality?
What is demo mode besides a boolean flag? Should we leave this functionality to a screens package or should we move that code somewhere else?

How we decide to navigate between the screens is up for another debate (react native nav vs router), but we can at least all agree on the JSX screens as Håvard mentioned.
What screens are we thinking about?

It is important to start thinking about how we solve navigation as well, since this is very much related to how we secure our screens behind a login. Is the vision to have apps use this package directly in the future, or is it more of an intermediary package?

[tormodAase]

I'm all for separating concerns as has been mentioned here. Should a screen package be responsible for exposing demo mode functionality?
What is demo mode besides a boolean flag? Should we leave this functionality to a screens package or should we move that code somewhere else?

We could make login screen use demo mode from another package, and authenticate/authenticateSilently from another package (mad-auth which implements react-native-msal?), and maybe onboarding could use language from another package as well. But I don't want the end user (the app developer) to put the puzzle pieces together in the app itself.

What screens are we thinking about?

LoginScreen, OnboardingScreen, ReleaseNotesScreen, Feedback/ServiceNow screen, SettingsScreen, and AboutScreen should be part of this package, IMO.

It is important to start thinking about how we solve navigation as well, since this is very much related to how we secure our screens behind a login.

We can also through this package, or another package, expose a Screen component that we wrap around all of our screens. The Screen component would require authentication by default.

Is the vision to have apps use this package directly in the future, or is it more of an intermediary package?

I guess for now, we would want the apps to use this package directly. I don't think we would be able to create a mad-navigation package without forcing the apps to use react-navigation instead of expo-router. I think Expo Router is something we will eventually implement, especially if the new typed routes are as amazing as they seem.