0

I am working in a large React App. In my top level parent component, I am adding some info (user data from login service) to local storage through a Flux action dispatch. Once that action has dispatched, the rest of the app is rendered but the visibility of some components is dependent on the status of that data in local storage (i.e. user read permission). Note that this is all validated on the server-side as well when I query to collect the data to populate these components, I just want to render them in the most efficient way.

Since these components are not attempted to be rendered until after the Action that adds the permission data has been dispatched can I assume that the permission data will be available to read from local storage in the constructor/componentWillMount of the child components? Or do I need to handle potential latency between writing to local storage and reading from it?

Edit: As per the comment below, I can store my user permissions in the Store instead which resolves that issue.

However, I also get a URI for an API from the login service that may change depending on the user. This URI is used for ajax calls in functions that are called by actions dispatched when the child components are mounted. Since this is a static entity, not a component of state, local storage seems like the better place to hold this over the store. So the latency question above still stands for this aspect, is it safe to assume that as soon as the child component mounts and the ajax call is triggered the URI will be available to read from local storage? Or do I need to handle potential latency.

Geoff McLennan
  • 418
  • 1
  • 6
  • 15
  • 1
    _the visibility of some components is dependent on the status of that data in local storage._ This is a wrong approach in React/Redux. Components should be dependent on data from the Redux store **only**. No direct dependency on local storage! If you want to serialize the store data in local storage you have to subscribe for changes in store or use a middleware. See [this answer](https://stackoverflow.com/a/35675304/2118955) for details – hindmost May 25 '17 at 17:58
  • Thanks, that is a better way of handling the permissions and view layer. However I have some further issues and I think my question still stands for them, see my edit. – Geoff McLennan May 25 '17 at 18:35
  • It seems that you still don't understand how Redux works). Never use extra source other than the Redux store for the app state. You only can use local storage for serialization, not for actual state storing. If request URIs are user-dependent, just build them based on the current user data. I don't see any problem here. – hindmost May 25 '17 at 18:49
  • This URI cannot be generated from the user, it is associated with customers in our back end. I agree that Flux should be exclusively used to store the app state, but I don't consider this to be part of the app's state, as it is a constant that happens to be initialized by the login service. It is never changed except when set during the login process. If the user is already logged in when the open the app, it will be used straight from local storage. That is why i believe my question still applies. – Geoff McLennan May 25 '17 at 19:11
  • _..it will be used straight from local storage._ Remember: **anything** related to components must be stored in the app state, without exception! This is also true for your URI. Login session cannot live forever, isn't it? Sometimes it expires and you have unlogged-in user. But your app should handle all cases. Hence your URI is **not constant** and must be stored in the state. However you can persist such data in local storage, but it can only be used as a backup for the state (which can be applied at the start if session is live). Components **should not** have direct access to this backup – hindmost May 25 '17 at 22:13
  • I'll repeat what I said above, the URI is not a part of state. Forget the login process for a moment, and assume that everything within the login wall is the app (the login page is static anyways). The URI is constant within the app. It is constant. It is set at the beginning of app execution (the response of the login service) and exists for its entire lifecycle. It can only be retrieved from the login service. It is a condition for the user being logged in, if it does not exist they are booted back to the log in page. This is the design of the app, I am not asking for advice on this aspect. – Geoff McLennan May 25 '17 at 22:39
  • I appreciate that you are trying to encourage best practice with Flux/Redux, but this is not my question. To rephrase my current question, if when my app is started I send a string to local storage, is it safe to assume that that string is immediately available to retrieve from local storage or do I need to account for potential latency. Thank you for helping with the first part of my question. – Geoff McLennan May 25 '17 at 22:43
  • _if when my app is started I send a string to local storage._ This is a strange and probably bad practice. Usually one does **reading** (from local storage) at the app start, not _writing_. Common practice is read once at the start and write whenever the state changes. In this case you don't care about potential latency between writing and reading. – hindmost May 26 '17 at 06:52

1 Answers1

1

Calls to localstorage are synchronous, so you can safely assume that if you set a value in localstorage, it will have completed before future lines of code are executed.

TLadd
  • 6,488
  • 2
  • 32
  • 40