I'm using redux and es6. I want to dispatch an action before components will mount. The problem is that with redux newest syntaxis componentWillMount doesn't exists any more. So... where should i dispatch this action.
My case: I have a component that needs user's info (such as name, for example). I need to get the user's name before that component mounts.
thanks,
Connect your component to a field in your state, let's call it "name". When the component renders, make sure it checks if name is not empty; if it is then it renders it, if not then it renders nothing.
In the componentDidMount, fire your dispatch as normal - this in turn will reduce and end up changing the value of "name" in your state. This will cause a re-render and will then show properly.
componentWillMount only exists server side, so it is usually not the best idea to dispatch actions from it, as if you just had your client side code, they wouldn't work.
Related
Does there exists a build in function that keeps on reloading the whole component until a boolean gets true. Bacause now before I can get some data I need to wait until a user has clicked a button in another component. But there is no relationship between those 2 components.
Does someone knows a way how to do this.
thx!
you can make use of Event Emitters in components to share information so that you need not wait for a user dependent action . Also make use of Service classes in order to pass information between components.
https://angular.io/docs/ts/latest/cookbook/component-communication.html#!#bidirectional-service
Also if you are getting information from a http call try and use observables or promises and then use ngIf or a elvus operator to get info into the component.
More on Angular Concepts https://rahulrsingh09.github.io/AngularConcepts/
I solved it by using a service where is create a subject/observable.
Check the link:
https://angular.io/docs/ts/latest/cookbook/component-communication.html#!#bidirectional-service
check the: Parent and children communicate via a service
Is there a way to know if the real-time document has changed in any way? I.E. I don't want to install event handlers on each collaborative string, list, map, and custom object. Instead I want to install one event handler to be called if ANY collaborative object in my real-time document has changed.
The only way I know so far is to periodically check serverVersion to see if that has incremented. But sometimes it increments even if nothing changes.
An ObjectChangedEvent listener added to the root will be informed whenever any change is made in any part of the model.
The ObjectChangedEvent is a bubbling event that is additionally emitted for every change. The ObjectChangedEvent is sent to the object that changed and all of its ancestors. One ObjectChangedEvent is emitted for every object that changed within a compound operation. The specific changes are described in the events field.
See also:
https://developers.google.com/drive/realtime/handle-events
I have gone through David Nolen's basic Om tutorial but I am still a bit confused about the difference between application state and component local state. When cursors are referred to is it referring to one or both of these too?
As I understand it:
Application state is the "global" state that all components in the component tree can access, through cursors. This is the state that your application is in and basically what is being rendered by Om. So, for example, if you are writing a chat program, the application state would contain a list of users in the conversation and all of the messages that have been sent, or whatever.
Component local state is state that is local to a single component and cannot be seen outside of this component. It is set either by passing {:init-state } to build, or by implementing IInitState and returning a map from init-state - or both (in this case, they are conj'd together). David Nolen recommends that local state should only be used for transient state, such as if the mouse is currently pressed in a drag/drop component and that all other state should be application state. That is, if you have a tab widget, the currently selected tab should be set in application state (not local state!), but if the tab is being dragged to a new location, the current position and mouse state would be (temporarily - until the drag operation is complete) be stored in component local state. Things like core.async channels can also be stored in local state (though I've also stored them (and seen others do the same) in shared state and additional data - see below for details on both)
Cursors only apply to application state and are like windows into it so that components far down the tree can access only the data that they actually need to access.
Application state is always accessed through a cursor (app in the tutorial) and modifying application state is done through a cursor - both om/update! and om/transact! take a cursor as their first argument. You can also set the application state atom directly with reset! and swap!, but David recommends against this as by doing that you lose out on some of Om's more advanced features (like being notified of change deltas).
Local state can be received through IRenderState or by accessing it directly with om/get-state. You can set local state with om/set-state! and om/upate-state!. All three of these take a component backing object (owner in the tutorial).
There is also a third type of state in Om: shared state. Shared state is passed to om/root using the {:shared ...} option and can be accessed from any component in the tree under that root, using om/get-shared. The difference between this and application state is that application state is narrowed down through cursor paths - that is, sub components may not have access to the entire application state - while shared state is always accessible. Also, modifying application state causes the component to be re-rendered while shared state does not trigger renders.
As an aside, there is actually a fourth type too - you can pass additional data to components through build using the {:opts ...} option. This is data that lives outside of the Om/react lifecycle - that is, its immutable data that you can access from a component, but the component does not manage it in any way. This seems to be most useful for configuration data.
First off, I've done a lot of research on the web (including this site) and have found lots of conflicting information on how the model and controller communicate in an MVC pattern. Here is my specific question (I'm using AS3), but it's a general MVC question...
I have two main components... a list of recipes and a form that displays a selected recipe. The form has an edit state that allows you to edit the recipe and then save or cancel the changes. What is the best way (using MVC principles) to handle changes made to a recipe? So far, I have the save button trigger an event which is captured by the controller.
Should I have the save button (the view) pass an object with the current state of the fields along with the event (some logic in view)? Should I allow the controller to hold access to the view and have the controller figure out what's in the fields on its own (added coupling)? Should events be made every time a field in the form is changed and the controller keeps track of the state of each field (lots of events)? Or is their another way? Note: I don't want to bind the fields to the model because I only want the data to save if the save button is clicked.
Any help would be greatly appreciated. Thanks!
Should I have the save button (the view) pass an object with the
current state of the fields along with the event (some logic in view)?
yes, this is not 'logic in the view', it does not decide anything, simply reporting an action and its current state
Should I allow the controller to hold access to the view and have the
controller figure out what's in the fields on its own (added
coupling)?
no, this would become very messy, pass a VO with the event
Should events be made every time a field in the form is changed and
the controller keeps track of the state of each field (lots of
events)?
is an option, but this basically is the same as hitting the save button, the trigger is different (TextField.onChange), but you can dispatch the same event (setup is form = view, dispatches one general event with a VO, not an event for each field)
Or is their another way?
MVC flow w/ events:
onClick save btn: a RecipeEvent.SAVE is dispatched (from the view), with a VO (value object) containing the Recipe data (e.g. RecipeVO)
the controller catches this, and as the controller is where the logic resides, it decides what to do with it: update the RecipesModel (either directly by calling a method on the model, or by a custom event e.g. RecipeModelEvent.SAVE)
the model stores the data, and dispatches the RecipeEvent.UPDATE event (with the RecipeVO)
the views updated itself accordingly (check if the RecipeVO.ID is same, update data representation e.g. title…)
optionally, a controller could save the data to a back-end/remote database
As for the event listeners: views listen to the model, controller listen to the views.
About de-coupling:
use interfaces (by using an IModel you can swap out the model easily by another implementation, as you register the event listeners against the interface instead of the actual implementation)
Obviously, all this results in a lot of registering/removing event listeners, and keeping reference to the models/views/controllers to be able to register to the appropriate instance. An alternative is to use a framework as RobotLegs, as it makes a central event-bus available + easy/automatic cleanup of event listeners in the mediator class of a view.
I think this is really a database question. what I would do is create a stored procedure that first checks to see if the recipe already exists. If yes then update it. If not then add a new recipe. (you'll have to bind your entity to a stored procedure. other MVC frameworks can do this. I don't know about actionscript)
if that's not an option then I guess you would have to cache the original form in a helper class in the controller and then compare it to what the user is trying to save. And have the controller decide whether to update the recipe.
I think it's much cleaner to use the first way, but I've never used actionscript so...
Colin Moock's lecture on MVC in ActionScript is quite old, but still one of the best explications: http://www.moock.org/lectures/mvc/
Your model should populate your view, and your view should send input events to the controller, which should decide what to do with the input. As g10 says, wait until the save button is clicked and then pass an object with the modified fields up to the controller for processing. The controller can then decide whether or not to accept it, and whether to update an existing model object or create a new one.
What exactly will this addActionListener Do.....we we call button.addActionListener(this) what will happen
It basically adds this (the current object) to a list of objects that will be notified when the component has an action performed on it, such as a button being pressed.
It's a way of registering your interest in what is happening to the component and is useful in that you don't have to keep polling a component to check its status.
Your object (or class, really) simply implements the interface methods for listening (such as actionPerformed) and that method will be called for each event that happens.
The Java tutorials have a large variety of different articles on the various listeners that you're likely to use.