I understand that getInitialState is called once in the component's lifecycle and componentDidMount is called when the component is rendered.
So does that mean both will get called just once in the component's lifecycle? What's the difference?
getInitialState is called at first instantiation of the component. It should always return an object and this object will be the initial state of this.state within the component. You don't have to define getInitialState if you don't want to, perhaps you don't need an internal state, in which case don't define it.
componentDidMount is called once the component is actually mounted to the DOM. But not, as you suggested, every time the component is rendered. If you're looking for something that runs every time the component is rendered (other than the render) take a look at componentWillUpdate and/or componentDidUpdate.
As for the main differences, getInitialState is quite literally just supposed to return the initial state for that component, nothing else. The function is executed long before the component is actually rendered to the DOM. componentDidMount is executed directly after the component has been rendered to the DOM, so for example you could now do things which require the component to be on the DOM first, such as using this.getDOMNode() to check the exact height of your component's root HTML element, or modifying it's scroll position.
You're right though, both will only be called once in the lifetime of an instance of your React component.
Related
I'm attempting to dynamically add Manipulation Events to a ManipulationHandler that is being added to child objects of a parent. The parent object will be what the user is inspecting, but the user will be able to grab parts off of the parent and inspect them more closely. (i.e. you can look at an engine (parent object), but if you want to inspect the pistons (child objects) you can grab them and look at them)
Instead of having to go into every child object and manually add it in Unity I'd like to be able to add the parent object and just procedurally add the ManipulationHandler and ManipulationEvents on start or awake.
So far I have the following code for adding the ManipulationHandler script, but to add the ManipulationEvent I'm not sure how to set up the pointers so I can use the script and function I want from the source:
gameObject.AddComponent<ManipulationHandler>();
ManipulationHandler handler = gameObject.GetComponent<ManipulationHandler>();
ManipulationEvent newevent = new ManipulationEvent();
ManipulationEventData eventdata = new ManipulationEventData();
eventdata.ManipulationSource = gameObject;
The program works when I grab the objects, but I'd like to add manipulation events when I grab them so I can display additional data.
I see there's a getter and setter for Pointer in ManipulationEventData, but I'm not sure how to instantiate IMixedRealityPointer and how to get it to work. I'm also not sure if that's the object I actually need to accomplish what I'd like to accomplish.
I apologize in advance if I've missed something obvious. I'm new to MRTK.
Thanks!
The ManipulationHandler has four callback events among them OnManipulationStarted and OnManipulationEnded you can simply add listeners to. (see UnityEvent.AddListener)
Unless I understood your question wrong you don't have to instantiate any IMixedRealityPointer. You don't create the event data yourself but rather the ManipulationHandler feeds these events with the current event data including the interacting pointer information. The ManipulationHandler uses OnPointerDown and OnPointerDragged and OnPointerUp via the IMixedRealityPointerHandler interface in order to manage the interacting pointers and invokes the according events where needed.
Instead of using AddComponent followed by GetComponent directly store and use the return value of AddComponent which will be the reference of the newly added Component. MRTK also has an extension method
T EnsureComponent<T>(this Component component) where T : Component
so that you can simply use e.g.
var handler = this.EnsureComponent<ManipulationHandler>();
which internally first checks whether the component already exists, and if not it adds it.
Note that in order to enable near interactions you will also need a NearInteractionGrabbable so you should add this one too.
You also will have to make sure that your objects have some sort of Collider attached to the same GameObject as the NearInteractionGrabbable.
...
gameObject.transform.EnsureComponnet<NearInteractionGrabbable>();
var handler = gameObject.transform.EnsureComponnet<ManipulationHandler>();
handler.OnManipulationStarted.AddListener(HandleOnManipulationStarted);
handler.OnManipulationEnded.AddListener(HandleOnManipulationEnded);
...
/// <summary>
/// If you need it later you need to store the pointer since unfortunately in
/// OnManipulationEnded the <see cref="ManipulationEventData.Pointer"/> is null
/// (no idea why they do it this way :D )
/// </summary>
private IMixedRealityPointer _pointer;
private void HandleOnManipulationStarted(ManipulationEventData eventData)
{
_pointer = eventData.Pointer;
// whatever shall happen when manipulation started
}
private void HandleOnManipulationEnded(ManipulationEventData eventData)
{
// whatever shall happen when manipulation ended
}
Note: I am not sure if this thing you are trying to achieve is possible with this architecture ... it is very possible that nesting various ManipulationHanlder leads to strange behavior here and there. Especially very small parts will be almost impossible to grab ...
I've been refactoring my app to make more components stateless/pure components; i.e., they're just functions. However, I noticed that some components will need to connect with the redux store via mapStateToProps. Which causes me to do something like this:
const someComp = (props) => {
const {
funcFromReduxStore,
} = props;
return (
...
<SomeComponent
func={ funcFromReduxStore(myArgs) }
...
);
};
This will not work because I am executing funcFromReduxStore. An easy solution is to wrap the prop in an arrow function. However, this causes many unnecessary re-renders b/c the function won't be bound.
The question then becomes: How do I bind a function in a stateless component?
Is it still stateless if I make it a class, without a constructor, and create a class instance field as so:
class someComp extends React.Component {
const {
funcFromReduxStore,
} = this.props,
wrapper = (x) => funcFromReduxStore(x) // equivalent way to bind w/ ES8+
render() {
...
<SomeCompnent
func={ wrapper(myArgs) }/>
...
}
}
I don't have a constructor, nor state. I want to keep the comopnent stateless, but I also want to bind the function to avoid unncessary re-renders. I also want to continue to keep it stateless b/c React has stated there will be performance benefits for stateless comopnents. Does this qualify as a workaround?
Short answer, no. Stateless functional components need to be simple functions.
You should take a look at the Recompose library for some really cool helpers that allow you to beef up your SFCs.
If you're trying to prevent unnecessary re-renders, you could look into onlyUpdateForKeys() or pure().
EDIT: So, I've been thinking about this a bit more and found this really great article on React component rendering performance. One of the key points in that article that pertains to your question:
Stateless components are internally wrapped in a class without any optimizations currently applied, according to Dan Abramov.
From a tweet in July 2016
So it appears that I was wrong. "Stateless Functional Components" are classes...for now. The confusing thing is that there have been performance improvements theorized:
In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations.
At this point, I think the answer to your question becomes largely subjective. When you make a class that extends a React Component, any instances of your class get the setStateprototype method. Meaning you have the ability to set state. So does that mean it's stateful even if you're not using state? Thanks to #Jordan for the link to the code. SFCs only get a render method on the prototype when they are wrapped in a class by React.
To your point about wanting to bind functions, there's only two reasons I can think of that you'd want to bind the function:
To give the function access to this (the instance of the component). From your example, it doesn't seem like you need that.
To ensure that the function passed as a prop to a child component always retains the same identity. The wrapper function in your example seems unnecessary. The identity of the function is determined by the parent component (or mapStateToProps, or whatever HOC).
You should also take a look at React's PureComponent which does the same kind of shallow checking that the pure() HOC from recompose does.
Can someone give a more detailed explanation about the lifecycle of the default events of a UI5 Control? I know there is this page on the documentation that gives an overview of a Control lifecycle, however, I think it is very brief and wanted something more detailed. Can someone list the order of the events of a Control and explain what every event does?
You are absolutely right. The details of a Control lifecycle and implementation details are very well hidden in the docs. I'll try to sum up my so far understanding for you.
The lifecycle of a Control is mainly determined by:
init : Your little Control is born! Function is called by the framework during constructor execution. Do your initialization stuff here.
onBeforeRendering : Called by the framework before the rendering of the control is started. Triggers before every (re)rendering.
onAfterRendering : Called by the framework after the rendering of the control has completed. Triggers after every (re)rendering.
exit : RIP little Control! Cleans up the element instance before destruction. Called by the framework. Do your clean up here. Btw: If you need to explicitly destruct a Control/Element you should call destroy and not directly exit.
Here is a sample implementation with some sample usages for the different hooks:
sap.ui.core.Control.extend("a.sample.Control", {
init : function() {
// instantiate a sub-control
this._btn = new sap.m.Button();
},
onBeforeRendering : function() {
// deregister a listener via jQuery
this.$("subelement").off("click", this.subElementClick);
},
onAfterRendering : function() {
// register a listener via jQuery on a sub-element
this.$("subelement").on("click", this.subElementClick);
},
subElementClick : function() {
// do stuff
},
exit : function() {
// clean up sub-controls and local references
this._btn.destroy();
delete this._btn;
}
});
Why shouldn't I do my init stuff in my constructor?
There is a basic UI5 constructor in ManagedObject. It "prepares" your UI5 object for you and calls your init function afterwards. That means in your init all settings will already be applied for you and you can access properties and aggregations as usual.
Why shouldn't I call rerender?
The SAPUI5 rendering is intelligent in a sense that it groups and optimizes queued rerenderings. Therefore you should never call rerender directly but instead use invalidate to mark a control for rerendering.
HF
Chris
UI5 provides predefined lifecycle hooks for Controller implementation. You can add event handlers or other functions to the controller and the controller can fire events, for which other controllers or entities can register.
UI5 provides the following lifecycle hooks:
onInit(): Called when a view is instantiated and its controls (if available) have already been created; used to modify the view before it is displayed to bind event handlers and do other one-time initialization
onExit(): Called when the view is destroyed; used to free resources and finalize activities
onAfterRendering(): Called when the view has been rendered and, therefore, its HTML is part of the document; used to do post-rendering manipulations of the HTML. SAPUI5 controls get this hook after being rendered.
onBeforeRendering(): Called every time the View is rendered, before the Renderer is called, and the HTML is placed in the DOM-Tree.
Source: ui5.sap.com/#/topic/121b8e6337d147af9819129e428f1f75
Is there any idea wich allows me using layouts declared in MyApplication.java from other classes and functions.
I tried put them in parameters it works but it becomes very complicated
For example xhen callin a function named Y in function X I have to pass all layouts on parameters like this:
X(layout1,layout2,layout3,layout4)
{
Y(a,b,c,layout1,layout2,layout3,layout4)
}
I tried to use a class named uiHelper but it didn't works
You can take a look at Blackboard addon for vaadin.
https://vaadin.com/addon/blackboard
From that page:
Sometimes, having a deep component hierarchy poses a problem, when you need to inform a component high up in the tree that something happened deep down below. You normally have one of two choices - either pass the listener all the way down the hierarchy, leading to more coupled code, or let each component in between be a listener/notifier, passing the event all the way back up. With the Blackboard, you can register any listener to listen for any event, and when that event is fired, all the listeners for that event are triggered. This keeps your components clean and rid of unnecessary boilerplate code.
For your example, you can create a LayoutChangeListener and LayoutChangeEvent.
MyApplication can then implements LayoutChangeListener and when a LayoutChangeEvent is fired, you can change your layout without passing it around.
I couldn't find any reference on how to use a parent form element in a subclassed form. May be because it's obvious to everyone but me. It's got me stumped. This is what I tried.
At first, within my form constructor I called
parent::__construct($options = null);
then accessed the parent elements like this
$type = parent::setName($this->type);
The problem was that ALL the parent form elements would display whether explicitly called or not. Someone said, "don't use __construct(), use the init() function instead. So I changed the constructor to init(), commented out the parent constructor, then ran the form. It bombed saying it couldn't pass an empty value for setName(). I commented out all the seName() calls and the form ran, but only displayed the elements instantiated in the subclassed form.
My question is this: If I don't use the parent constructor, how do i get and use the parent's form elements?
Solved: Since the constructor was switched to init, the call to the parent also needed to be switched. Easy for someone with php background. Not so much for one who doesn't.
Use
parent::init();
Solved: Since the constructor was switched to init, the call to the parent also needed to be switched. Easy for someone with php background. Not so much for one who doesn't.
Use
parent::init();
You should learn OOP principles first. Obviously you have no understanding of it whatsoever. You need to call parent::init() in you Form_Class::init() method as you wrote, but why? Because otherwise the parent method is not called and is overriden by the From_Class method.
Other thing is that when you have a parent class "SuperForm" with input and submit, then your "SuperForm_Subclass" would have the same elements assigned. There is no need to use "parent::*" to access element (only exception would be if you used static SuperForm variable to store them - which makes no sense).
You can easily use $this->inputElement and $this->submitElement inside your SuperForm_Subclass like you would in the SuperForm class.
In your example you could used the __contruct() as good, but with the same condition of calling the parent constructor. You would be able to access elements generated there too...