I have an application that has hundreds of screens. I usually pass the variables from parent to child between the components with props. I find it very uncomfortable to pass the array with the user information hundreds of times.
I am testing the global variables of react native. Does it have any danger to use a global variable to save user information and modify it within the components?
I have searched for documentation and nothing is said. I know it's not correct in react, but it works wonders for me.
Any recommendation?
If that global variable is a constant or it's value doesn't effect rendering of components then you are good to use it as global variable or async storage.
But if it's value is changing and affecting the rendering of component then I highly recommend you to store that value as state and to make it global you can either use
1) Context api (https://reactjs.org/docs/context.html)
2) Or Redux
Related
I am looking for information on where Vue stores the cached component data when a component is wrapped in the keep-alive component. I looked at the local storage, cache storage, and session storage but I don't see anything obvious. I suspect that the cache is stored in the DOM but I was hoping that someone might know for sure or offer some clarification.
The issue I am having is that I have some Vue components that I am wrapping as web components using https://github.com/vuejs/vue-web-component-wrapper. This library is responsible for adding the keep-alive to my vue components. These components are then used inside other front end frameworks. The keep alive doesn't work as expected in this scenario, if I navigate away from the component and return the component is not restored to it's previous state. What I am expecting to happen is that navigation away from the component and returning restores the component to it's previous state as described in https://v2.vuejs.org/v2/guide/components-dynamic-async.html
After some digging around - in the implementation of keep-alive (Here).
You can see that the cache is stored locally on the component level, meaning that if the <keep-alive> is removed from the DOM it will lose its stored cache.
In theory, if you need it another way you may extend the component - create a prop like cacheName that you pass down to it. Have on mounted check if there is anything in localStorage for that prop to supplement it. Then add a watcher (deep) to watch for changes to the cache and store it in LocalStorage with the key coming for cacheName.
Some rough code of how the component may look - Here. Keep in mind that it may not be possible to get the object from Vue this way so you may need to copy the whole thing then add the code on top of it.
I'm using react-native-google-places-autocomplete for google places auto-complete.
I'm creating a new page to edit the address and I want to use the setAddressText function to insert the last current address before the editing.
I tried to create a ref and store it with redux of the google autocomplete component but since this search bar rendered only when clicking on the edit button the reference hasn't created and I cant use the setAddressText on the ref.
Does anyone have a solution for that?
You use either useRef or createRef to create the ref object. Before calling any methods on it, you must make sure that myRef.current has been set. The easiest way (if your environment is up-to-date enough to support it) is with the optional chaining operator ?.
myRef.current?.setAddressText(someText);
However I would advise against storing a ref in redux. As a best practice, it is advised that everything in your redux state should be serializable — a ref is not.
I have a component library where i would like to standardize the props, component etc.
Thoughts on combining them props/methods/other mixins/etx into one larger mixin
All property names would be the same
Remove duplicated code on refactoring to adjust components from local props/methods/computed/ to "global"
Not all components would have need for every piece of data contained within the mixin - point 4
Would tree shaking remove the unused code on Rollup?
Is this a good idea?
If your component library is not constrained to using Vue 2 you might want to take a look at Vue Composition API to share functionality (methods + reactive state) between different components.
Mixins might not be what you really want to be using because you kind of lose information as to what features/props/methods really will be put inside your component without re-checking the mixin code. You also might run into issues when component options get merged by Vue at runtime. Check out these posts for more information:
https://css-tricks.com/how-the-vue-composition-api-replaces-vue-mixins/
https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html
As for sharing props: What I've seen just yesterday (but not yet tried!) in a talk by John Leider - creator of Vuetify - is create a function that returns the props you want to reuse between components. Then you just call said function inside your props definition and use the spread operator.
I have a VueX state that contains a list of items. E.g.:
{
operations: Operation[]
}
We need to display each Operation as an item in a list. So we have an OperationList component and an OperationItem component.
When it comes to rendering the list (v-for), would it be recommended to pass the entire item as a prop or just the id and have the OperationItem read the data from VueX?
Basically:
<operation-item v-for="operationId in operationIds" :id="operationId" :key="operationId"/>
vs
<operation-item v-for="operation in operations" :operation="operation" :key="operation.id"/>
I think it might be a preference choice but in my projects I usually pass all the prop of the components that way :
<operation-item
v-for="operation in operations"
:key="operation.id"
:prop1="operation.prop1"
:prop2="operation.prop2"
:prop3="operation.prop3"
/>
I'm not sure if that's a good practice or not but in this case, it's more flexible, you don't need to give a structured object for it to render, you just have to give it all it's properties.
A bit like for a class constructor, I would pass all the necessary parameters separately instead of passing them in an $option array or Settings class.
For some components, it also doesn't make sense for them to be aware of the store, they should juste be "stupid" rendered components.
I hope it's clear enough that you get my point !
I'd say pass the entire item. That way your component doesn't need to know where the data came from and you would be able to reuse the component in situations where the data didn't come from Vuex.
This is kinda a vague question
I have a React Native component that is going to be used in a ListView, each one is going to be slightly different in the sense that each component is populated different information in its props, each component also needs a mobx store to help pass information. Is there a way to dynamically create Mobx stores so each component has a Mobx store?
I was almost thinking like have a base mobx store class that each component uses, but not sure if this is the correct approach
When I understand your question right, you have the same data, but every list shows this data in a different way?
For that case you would create a computed prop for every list.
Fetch the data once, store it in a observable prop but let your lists use the computed props. In the computed props transform or do whatever you want with the fetched data.
https://mobx.js.org/refguide/computed-decorator.html#-computed