import {makeAutoObservable} from "mobx";
class Test {
id = 0
constructor() {
makeAutoObservable(this)
}
get total() {
console.log('enss')
return 2;
}
}
const store = new Test();
export default store;
call:
import {isComputed, isComputedProp} from "mobx";
console.log(isComputedProp(Test, 'total'),Test.total,Test.total, Test.total, isComputedProp(Test, 'total'))
console output:
enss
enss
enss
true 2 2 2 true
the computed did not work and does not serve as a cache.
i using mobx 6.6 version in react 18.
Thank you very much for your answer！
This is explained in the docs here
It sometimes confuses people new to MobX, perhaps used to a library like Reselect, that if you create a computed property but don't use it anywhere in a reaction, it is not memoized and appears to be recomputed more often than necessary. For example, if we extended the above example with calling console.log(order.total) twice, after we called stop(), the value would be recomputed twice.
Basically it won't be cached if you use it outside of reactive context.
You can use computed({ keepAlive: true }) option to change this behaviour
Related
Consider the following code:
const router = useRouter()
await router.push({
name: 'NonExistingRoute', // no typescript error ):
})
A non existing route name was given, but no TypeScript error happens. Instead the issue will only be noticed on runtime. Any way to get a compile-time error on this?
Perhaps you could wrap this in a utility function that only accepts typed route strings
const router = useRouter()
export type NamedRoute = "login" | "logout" | "user-profile";
export async function goToNamedRoute(name: NamedRoute): Promise<void> {
return router.push({name});
}
In short no.
For a compile error to exist there would need to be something explicitly wrong with the code, referencing an non-existent file, syntax error, etc.
It does sound like you are trying to solve some other issue here...i.e. why do you have the names of non-existing routes in your app?
In any case, perhaps you can avoid your errors programmatically, e.g.
let r = router.resolve({name: 'NonExistingRoute'});
if (r.resolved.matched.length > 0){
// exists
} else {
// doesn't exist
}
If you want to rely on Typescript for detecting wrong routes you might just use enums or closed types maybe?, although that will surely require some composition. Probably one way to go could be:
enum Cities {
NY,
London
}
function routeCreator(city: Cities, restOfPath?: string){
//combine paths somehow, e.g.
if(!restOfPath) return `/${Cities[city]}/`;
return `/${Cities[city]}/${restOfPath}`
}
I've used MobX for a few years now, and love it, but sometimes my trace calls are not functioning, and I don't understand why not. There must be some fundamental thing that I've completely misunderstood, but most likely have been lucky enough to get through anyway. Here's an example of using trace() where I'm getting an error:
import { computed, observable, trace } from "mobx";
class Stat {
#observable baseValue = 1;
#computed get value() {
trace();
return this.baseValue;
}
}
const strength = new Stat();
strength.baseValue = strength.baseValue + 1;
The expected output, in my mind, is that trace reacts to the change in "baseValue" and logs the change. Instead, I'm getting the following error:
Error: [MobX] 'trace(break?)' can only be used inside a tracked computed value or a Reaction. Consider passing in the computed value or reaction explicitly
"Inside a tracked computed value" is, to my understanding, exactly what I'm doing. Or..?
Full sandbox: https://codesandbox.io/s/mobx-trace-trouble-ki2qj?file=/index.ts:0-312
As far as I understand this phrase
inside a tracked computed value or a Reaction.
you need to access computed value inside reactive context, like inside observer or reaction or autorun. Otherwise trace just don't have information about what is going on because your computed value is untracked at that moment by any observer.
So this will work:
const MyComponent = observer(() => {
return <div>{strength.value}</name>
})
or this
autorun(() => {
console.log(strength.value);
});
In several Vue files this computed property checks if this.data is not an empty object:
computed: {
isLoaded() {
return !(this.data && Object.keys(this.data).length === 0 && this.data.constructor === Object); // checks if this.data is not empty
}
}
Then isLoaded is used to conditionally display content in the browser.
I'd like to refactor the code and create a global method somehow that can check if an object is empty so all the files that use this method can get it from a central spot.
Even after doing some reading on Vue mixins and plugins I'm not clear which one best fits this use case. Which one should be used for this? Or is there an altogether different approach that would be better to create a global method?
There are several ways to do it and it and approach depends on particular case. For your case I'd suggest you to create a separate folder for utils functions, where you could have smth like common.js. There you can just export your functions e.g.
export const emptyObj = (obj: any): any => Object.keys(obj).length === 0;
and import it in your component:
import { emptyObj } from "src/utils/common";
In this case it easier to organize your shared functions, easier to test them and have typescript support.
In VueJS I have a vuex store getter which may throw an error of type ErrorOne or ErrorTwo.
// myGetter.js
export class ErrorOne extends Error {}
export class ErrorTwo extends Error {}
export default () => {
if (...) {
throw new ErrorOne()
}
if (...) {
throw new ErrorTwo()
}
return ...
}
And in a computed property in my Vue component I am using this getter but I want to handle these errors in a try catch block.
// MyComponent.vue
import { ErrorOne, ErrorTwo } from '.../myGetter'
export default {
...,
data() {
return {
errorOne: false,
errorTwo: false
}
},
computed: {
myGetterComputed() {
try {
const value = this.$store.getters['.../myGetter']
this.errorOne = false // Unexpected side effect
this.errorTwo = false // Unexpected side effect
return value
} catch (err) {
switch (err.constructor) {
case ErrorOne:
this.errorOne = true // Unexpected side effect
break
case ErrorTwo:
this.errorTwo = true // Unexpected side effect
break
}
}
}
}
}
But eslint tells me [eslint] Unexpected side effect in "myComputedGetter" computed property. [vue/no-side-effects-in-computed-properties].
What is the correct way to handle errors in Vue computed properties in my use case?
Should I move myGetterComputed to data and use a watch method to handle updates?
If I am going straight to answer your question I can tell you that eslint is using this rule to warn you about an unintended side effect. As per the eslint-plugin-vue docs
It is considered a very bad practice to introduce side effects inside computed properties. It makes the code not predictable and hard to understand.
Basically what we need to remember is that computed properties are meant to be used when there's heavy logic associated to how we treat data inside templates. So you shouldn't be updating any properties/data inside a computed property logic.
I would like to help you further if you provide a more detailed example of what you're trying yo achieve
We created a simple MobX store to save an object. This MobX store also syncs with AsyncStorage every time fooObject is changed:
import { observable } from 'mobx';
class FooStore {
#observable fooObject = {};
setFooObject(newFooObject) {
this.fooObject = newFooObject;
this.syncWithAsyncStorage();
}
syncWithAsyncStorage() {
AsyncStorage.setItem('fooObject', JSON.stringify(this.fooObject));
}
This mobx store is then consumed by various screens in the app.
As you can see, we use RN AsyncStorage, which is kind of a LocalStorage but for native apps, to always store the current state of fooObject.
The question is: when the app is closed, we loose FooStore state, so we want to retrieve the last 'save' we did to AsyncStorage (which is persisted).
The problem is AsyncStorage is (as the name states) an ASYNC function, and we can't wait for a promise resolution in FooStore's constructor.
How one would accomplish this initial state initialization of this MobX store based on the resolved return value of AsyncStorage?
We thought about writing an initialization method (async method) in FooStore like this:
async initializeFromAsyncStorage() {
this.fooObject = await JSON.parse(await AsyncStorage.getItem('fooObject'));
}
And then call this method on app initialization in our root App.js.
But I'm not sure if this would present unintended side effects and if this is idiomatic mobx/react-native.
Yes, I would create an initialization method. If the instance is not dependent of the initial data, you could call it right after the instantiation:
const fooStore = new FooStore()
fooStore.initializeFromAsyncStorage()
export default fooStore
Thill will not guarantee that the initial data is loaded when the app is constructed, but since the data is an optional observable, your app will react to it if/when it’s available.
Remember that AsyncStorage.getItem will resolve null if it has not been set, so you might want to do:
async initializeFromAsyncStorage() {
const result = await AsyncStorage.getItem('fooObject')
if (result !== null) {
this.fooObject = JSON.parse(result)
}
}