Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase 'W'.
Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase "W".
Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase 'W'.
Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase "W".
Currently in `render`, you can only return one node; if you have, say, a list of divs to return, you must wrap your components within, say, one big `div` or `span` (or any other component).
Currently in `render`, you can only return one node; if you have, say, a list of `div`s to return, you must wrap your components within, say, one big `div` or `span` (or any other component).
Don't forget that JSX compiles into regular js, and returning two functions doesn't really make syntactic sense.
With a controlled input component, specifying a `value` prevents the user from changing the input unless you desire so (more info [here](forms.html)).
You might have ran into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited.
You might have run into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited.