I'd like to have an autorun (or any sort of reaction) that runs when it notices a cookie change/set. At the moment I'm using an observable boolean that flips when I make a change but it feels a bit messy. Any way to make a cookie observable?
I wrote my own package to deal with this: https://www.npmjs.com/package/mobx-cookie
Related
My app consumes an self made - HTTP REST API. I use vueX for state management.
I have some nested components that needs access to the same http result as the parent, but I also use the component in other places where the parent does not fetch the result. Is there a way (pattern) to make sure a resource is not fetched multiple times.
I found this, and like the way of doing things, but I can't figure out how to make a new request to the server for updating the result. https://tkacz.pro/use-vuex-to-avoid-multiple-requests-from-different-components/
and is this even best practice ?
anyone has a better way ?
Using vuex and checking if your state is already populated is good enough. If it's not, then call a vuex action. It will help you to have a state shared globally in your app.
Not sure about this part
how to make a new request to the server for updating the result
What would be the issue or calling the API a second time? If needed, you can use the suggested solution in the comment, like adding a ?refresh or even and id to it id={randomId}.
I have a mobile app made in React Native, and I've just run into a best practice dilemma i've encountered many times while using Redux/Redux Saga. I would love if i could get someone else's thoughts on this.
For a new piece of functionality i'm implementing, i need to be able to tell how many times the app has been launched. This involves asynchronously retrieving how many times the app was previously launched from the device storage. If there's a new launch happening, i also need to add +1 to the number and store that in the device storage.
This is how i currently do it:
Dispatch appLaunched() action when app launches.
Redux Saga takes event.
Inside Saga: Retrieve how many times app was previously launched (appLaunchCount) from device storage (wait for async to finish).
Add +1 to previous appLaunchCount.
Store new appLaunchCount in device storage (wait for async to finish).
Dispatch put() with new appLaunchCount to reducer.
Update state with new appLaunchCount inside reducer.
My problem with this method is step 6. Technically any part of my app could dispatch a new app launch count to my reducer, with any integer, and the reducer would update the state just the same even though it didn't come from the saga.
My question is this: How can i protect my Reducers/Sagas/Actions so that only my saga can dispatch the action with the current appLaunchCount ?
P.S The only solution i can think of is writing my saga and reducer in the same file, and use private actions that only the saga and reducer can access. I would really hate to have to keep all that code together though.
Private actions aren't really a thing. The store is, by design, a global object. And since actions are just objects with a type property, anyone who can construct an action object of the right type can in principle dispatch an action and kick off your reducer.
What you could do is make the action have a type that makes it obvious that it's meant to be private. For example, maybe the action looks like:
{
type: '__PRIVATE_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED__'
// You could tone it down a bit from this :)
}
That of course doesn't make it actually private, but at least if someone wants to use it, it's impossible for them to not realize your intent.
If you wanted to make it more secure, perhaps you could use a symbol as the type, and therefore only anyone with access to the symbol could construct the right action. For example:
const appLaunchCount = Symbol('appLaunchCount');
// action would look like:
{
type: appLaunchCount
}
But then the issue is making sure that symbol stays hidden, and can be accessed only by those who you want to access it. Similar to one of the things you mentioned, if you have the saga/reducer in the same file, then you could make sure that other files couldn't access this symbol; but once you start exporting it it becomes harder to control.
I am developing a Chrome app that uses some NPM's. When a dependency in my app uses window.localStoarge is there a way that I can map that to chrome.storage.local?
I want to override window.localstorage with something that works with chrome.storage.local instead. This way I do not have to replace code in dependencies that are using local storage.
Is there an npm or something that can do this?
First problem is that chrome.storage APIs are asynchronous and localStorage is sync. It is theoretically possible to create localStorage mock backed by the chrome.storage, but it will break in many cases.
Second problem is that chrome.storage operates on objects, when localStorage only allows strings. So if you'll have some kind of code which will rely on localStorage mode, you will have only store strings in chrome.storage.local, otherwise you will have very weird bugs.
Last problem is that you can't reassign window.localStorage variable in chrome apps, so the only way is to wrap the code into self executing closure, and provide window and localStorage mocks as closure variables, e.g:
(function(window,localStorage){
//some code relying on localStorage here
})(windowObjectMock,windowObjectMock.localStorage);
It is easier and more error-prone to rewrite the external code to use chrome.storage.local rather than trying to provide localStorage implementation backed by chrome.storage.local.
I'm currently using redux and redux-thunk middleware.
When it comes to controls regarding action dispatching, such as:
does the user have sufficient permissions for this action?
prompt the user to confirm his action (for destructive action)
I believe placing such controls inside async actions (thunk) is the way to go, because:
it keeps my code DRYer (many components/views could trigger the
action, whereas there is only one actionCreator for said action)
it's the last point before "something happens" in the app. Making it feel like a strategic place to make such controls.
The question(s)
I'm looking for feedback from other redux users. I'm fairly
confident of this decision, but having little feedback (and being
junior dev) makes me doubt. Is this the right way to go for
authorization controls when using redux?
What about making the authorization controller into
middleware. It would keep auth controls in a single place instead of duplicating it in every actionCreator.
Edit
When digging deeper into this possibility it quickly became challenging because middleware initially only receive (dispatch, getState) meaning that an authorization middleware would need to "know" which action is being dispatched (or which actionCreator is being used), something that required a hacky-ish setup and eventually proved un-reliable.
Other points
Yes, this is client-side. Yes, we also make server-side checks.
I know that these types of controls should NOT be in my store/reducers. They need to be pure.
I think you are good to go with your setup. Thunk is a good way for orchestrating your program-flow. There are also other Middlewares like redux-saga which is a bit more sophisticated but as far as i understand you want to do something like this (pseudo code)?
function authorizeAndTriggerAction(forUser) {
return function (dispatch) {
return authorizeUser().then(
action => dispatch(concreteAction(forUser)),
error => dispatch(notAuthorized(forPerson, error))
);
};
}
This can be done with thunk.
My store.sync() can return success:false, and if it does, I would like to use something similar to Ext's failure callback to react to the error appropriately, but I did not find a possibility to use any builtin ST functions for this. sync has neither callback nor success nor failure option available in ST.
What did I overlook?
PS: I did find a workaround for success callback at Why is there no sync callback in Sencha Touch? but I need failure callback.
store.sync() is not where you need to look. Take a look at the proxy. Most likely you are using an Ajax request and that in turn will deliver a detailed success and failure.
I am now calling Ext.data.Model.save() on all Ext.data.Model instances that are dirty. This won't batch everything neatly together, but in 90% of the cases, only one item is edited anyways. The best is that this allows to check for failure on each and every item, and not only on the whole batch.