I’m looking for some kind of a design/architecture advice. I’m using re-frame with React Native app, and navigation is built on top of React Navigation. I ran into issues recently because I didn’t realize that React Navigation doesn’t unmount previous component on navigation stack when pushing the next one, and if two screens on navigation stack subscribe to the same data this might result in a mess. Is there any guidance/recommendations how to handle this in React Native? Besides the obvious (having a separate app-db area for each screen, with duplicated data if necessary)?

Another correlated question: there’s a lot of data which should be naturally shared (like network loading status). But in case of invisible mounted components this will result in a lot of unwanted reactions (for ex. if every screen subscribes to (get-in db [:app-state :loading]), and I pushed several screens onto the navigation stack). What would be the best way to handle it? Keeping those things separately for every screen would result in a lot of boilerplate code.

better ask in #cljsrn or #re-natal i have simple case when using react navigation but to each screen has separate data that it depends on. They don't share data. Is it required that these components share data? Maybe this is sign that they don't need to?

the channel is #cljsrn ^^

oh right 😄 tnx

@lepistane there’s a case of application context which should be retained once user pushed a certain screen on top of navigation stack (all subsequent screens may re-use data from this context) I do agree that it’s generally safer not to share this information, although this could have been convenient

the question is not very RN specific, actually; it’s rather about proper usage of re-frame approach

Hi. I am looking for best practices on how to build a re-frame library. For example an "auth" library which provides views and event handlers for registration, login, logout, etc. I am not sure how to pass app specific data to this library. Information like logo-url, welcome-text, supported-oauth-providers, event-to-call-after-login. Should I pass these as parameters to views? Or should I place them in the db?

What if the configuration parameters for the library are more complex and need to be functions? Is it good practice to put functions into the db so that event handlers from the library can call functions placed in the db?

To take on one part of that question - I would not recommend putting any functions into the db. One option to get around this is to pass events as data that could be dispatched by your lib as an effect

on-success and on-error in this example are dispatched by the lib and mapped to registered handlers

What is the argument for not putting functions into db? Because this seams to make things very difficult. For example the library verifies the user name while registration, while each application can implement it's own username validator. Therefor I would put auth.validate-fn into db and the library could call this function while the user is typing or after form submit. Using events or effects for this seams more complicated. What am I missing here?

using the re-frame event system is more idiomatic and allows consumers to inject and inspect what’s going on inside your library better using normal re-frame machinery

I’m not sure why you would need to put functions in your app-db anyway, rather than just closing over them when you register your libraries events / effects / subscriptions

the app-db should be for your application domain data. putting things like functions in it seems wrong

one concrete problem with putting functions in the app-db is it prevents consumers from easily serializing the DB to e.g. localStorage or some other persistence as EDN

^ yes - So I would shy away from using a lib that stores functions in the global db because of serialization - I persist parts of app state in localStorage / send it to an error reporting services and that typically causes problems - also rehydrating an app with that state is problematic.

Thank you for your useful tips. So how to deal with optionality in this scenario? Say, my auth library supports this custom user name validation from the using app - but it is optional, the app does not have to provide a custom validation. In this case the library should use the default user name validation. Is there a way to ask re-frame if a specific event handler or a specific effect exists before calling it?

I see that re-frame events are the right way to model the "application flow". But it seams that I want to create a library, where the application which uses this library needs to "configure" the application flow. So I am not sure if such configuration of the application flow should also be implemented as re-frame events/effects.

How about this: The library does not register events on load. Instead it provides a function initialize which my app has to call. This function gets a configuration map with all customization values and functions. Then it registers it's re-frame events and effects, which have acces to the enclosed configuration map. You think this is a valid approach?

that sounds reasonable