Is there a way to fire a resolve function of a parent state again, after i transitioned from a child state back to its parent state?
Think of a service which holds an array of objects.
For "security" reasons, my service only gives out copies of the objects it's holding, to prevent direct manipulation from the controllers.
The array of objects is retrieved from my backend and saved in the service, the first time i go to the parent state and is resolved to this parent view.
If i transition to a child state, my service hands out one object of this array to manipulate it. After manipulation, changes get saved by my service and the original array gets updated with the new manipulated object.
After this, i transition back to my parent state, but because of ui-routers nature, the resolve function isn't fired again. My parent state displays the old array instead of the updated one.
But of course, i want the new data loaded. I dont want to work with broadcasting events, or manually retrieving stuff from my controller (in this case). I can't use the reload param of ui-router because i need it to work on window.history.back() as well.
Any ideas how to solve this? I could get it working the way i want by not using nested states (no child states), but actually, thats not a real option.
So the only option i see at the moment, is not to work with copies in this case, instead just use references.
Related
I need to send the data from the child component to its parent(by emitting), once the child is loaded without calling any event like click or keyUp,...
in other words, I want once the child component is mounted, it automatically sends some of its data to the parent and not necessarily calling an event to emit the data.
is there any way to do that in vue.js?
I'll thank you in advance
Instead of using the $emit i suggest using some store (state management).
It could be global store or sub store. A thing that will make it easier to watch changes in any parent/child components.
Imagine that you want to listen inside a very deep child component from a parent one. Would you start passing around events ?
The flow is :
1- Update the store from deep nested child
2- use a store getter in your parent component to watch/compute changes
Checkout vuex https://vuex.vuejs.org/
I suggest you read about how props work: https://v2.vuejs.org/v2/guide/components-props.html
One thing you could try to do is pass an Object as a prop, and mutate that object inside the child, than monitor object changes in the parent. But to be honest that conflicts with the ideas of how Vue works, and is based practice. So don't do it.
But what is the problem really? Emitting a custom event is by far the easiest thing to do, and fully in line with Vue.
In parent:
<my-comp #initiated="handleInitiated"/>
In child, after you did the initial work:
this.$emit('initiated', initiationData)
If you are worried about event propagation when using default event names, this solution with a custom event name solves that. Of course you can also always stop further propagation once you caught it.
I am new to React and a bit struggling with state in React and how and where we need to use it. So far, I found out that "If modifying a piece of data does not visually change the component, that data shouldn’t go into state". So, state is all about re-rendering the UI(I hope I am correct). So, the question I want to ask is Is it true that we use state only for re-rendering the UI only?, nothing else and nothing more?
You can use state in your class components. State is like private data of your component that may change by action made by user.
State is immutable. This means you can not change state directly in following way this.state.someVal = "smth". The only way to change state is using this.setState() method.
When you change state value React automatically re-renders your component without refreshing the page. In other words React.js reacts to your changes
State is an object that is directly tied to rendering the component. The reason why you can't change State directly with say this.state.foo='bar' is that React would have no way of knowing that it needed to re-render the component if you did that. Thus there is a setState method to change the state, which under the hood calls the render function of your component.
Therefore, if you have some data that has nothing to do with rendering the component, you don't want to put it into state, as setting its value will cause unnecessary renders to occur. If you're using class components, you can just put that data on the class directly: this.foo='bar'.
Basically yes! Two examples might be: A - holding a list of items (shopping list, or todo items) that are rendered directly to the UI, that are subject to change as the user adds and removes items. B - a value that determines whether or not you want something to show up on your UI, for example, you might have a state value called 'showNavbar' that is either true or false, depending on whether you want the user to see a navigation bar.
I hope that helps make sense of it in a basic way :)
We use the state for rendering the UI.
Also, I think the State allows React components to change their output over time in response to user actions, network responses, and anything else, without violating this rule.
For this, We use the 'setState' method.
setState() is the only legitimate way to update state after the initial state setup
Scenario: I have an react app which has its state in flux store (async load), passing data down to Root component which is passing data to its children and so on.
now: text input field, nested somewhere deep down in node tree, has its initial value done in getInitialState from a prop (the prop has been passed down), and on onChange event its state is set to typed value. So far book example.
Now let's 'submit' the form, action is triggered, ajax call has been made, data came back changed, passed to the store which emits event to Root component, the node tree gets re-rendered again, BUT of course getInitialState is not triggered again, and the field still has the last typed in value.
I don't think I want to initiate the whole action-store-root-children-reRender loop on every single key stroke, right?
Question: How do I get the input's state to be fresh from the passed prop (the store one)
THOUGHT: Hmm, I can actually tell when I'm initiating re-render from the ROOT, by setting a store 'flag' in ROOT's componentWillUpdate() then setting it back in componentDidUpdate() - then all the child components can know if it is ROOT intent to re-render or just a parent non-store initiated change.
Keep the form's values in the store instead, and don't using any local component state at all. When the form is edited trigger actions to update the store and re-render the app.
First of all what you are doing is an antipattern. State should not be set equal to props. Your props should not be state.
The React docs are pretty clear on updating props.
Check out this link: https://facebook.github.io/react/docs/component-specs.html
componentWillReceiveProps(object nextProps)
You should think about implementing this lifecyclemethod it will help you to be aware of prop changes.
But please think about seperating props and state - there is a reason why React Framework has both. But that is a different topic.
EDIT1:
If you want to update your stores state then call a flux action that referes to the corresponding store and pass in the props as payload inside of the lifecyclemethod above.
Hope this helped.
I'm quite new to AngularJS as well as Ionic. Was wondering if anyone could help me figure out how to set a certain history before a state change?
Currently I have $state.go('app.lineup',{ 'lineupId': navURLID}); and I want to point the back button to 'app.lineups' which is the parent for the 'app.lineup' page.
Everything in my code works well however when I redirect a user to another state the back button returns me to the state I sent them from and not the parent state that I need to send them to?
Any help (even in the form of internet references wink) will be greatly appreciated :).
Thanks a mil!
one way to do it is to not make the parent state as abstract, let it actually resolve the route and in the parent states controller redirect to the desired child something like
$state.go('parent',{child:'childname'})
where child is not a param but a search param, and from inside the parents controller you do
$state.go('parent.'+search.child,{any: param})
that way you'll always go through the parent state first.
other solution would be to use replace or you can also use the replace property of the options object in the $state.go function
https://github.com/angular-ui/ui-router/wiki/Quick-Reference
it depends on your structure.
I'm having an issue with KnockoutJs right now. I am a beginner, so for now I'm blaming my ignorance.
I have an observable array in a viewmodel. When any of the children are updated (which I verified through the console that they do in-fact change), I need the array to trigger a reflow/refresh of the view.
Here's why. My view creates an accordian based on the children, so grouping is involved. If a child changes it's group, it needs to move to a different place.
I did check out this SO How to force a view refresh without having it trigger automatically from an observable?
But observable.valueHasMutated() doesn't do anything. No errors, just nothing happens.
If anyone has a working example that I can learn from, or solution, that would be awesome.
I would post my code (and I may later if I can make it simple enough), but it's unfortunately not as easy as it sounds given the design of the app.
From the documentation:
Key point: An observableArray tracks which objects are in the array, not the state of those objects
Simply putting an object into an observableArray doesn’t make all of that object’s properties themselves observable. Of course, you can make those properties observable if you wish, but that’s an independent choice. An observableArray just tracks which objects it holds, and notifies listeners when objects are added or removed.
So you need to make your "group" property observable and make sure your binding handler reads the observable within its update function.