Minor changes for React 16 #80
Conversation
With React 16 "ref" must be null, not undefined, or you get errors while rendering: > Error: Expected ref to be a function or a string. See facebook/react#10649
Note: there could be further changes. The release is mostly backward compatible but there are some new things I haven't included yet that are probably worth including, here's a checklist:
|
Nice, we also need to modify |
Nice! There's also ReactDOM.hydrate() |
Note: the documentation link points to the blog post, as this isn't included in the official React API docs yet (even though the React API docs seem to have been updated at the same time as the release?)
@kLabz ReactDOM.hydrate() is already in the PR :) @elsassph for PropTypes - is that just a case of changing I was wondering if this needs a compiler define for switching between versions, but I don't think so - using |
I thought about doing conditional compilation with a define to use the old import, but the new import should be compatible with old versions of React so I think I'll leave it.
@elsassph regarding render being able to return a String or Fragment (array of JSX nodes)... I think this has more to do with the JSX parsing macro than the types. The macro should now accept those types, and spit out a In terms of whether to merge now or later, I'm in favour of merging this set of changes now, and working on any JSX adaptations needed as a separate PR. Whether to do a haxelib release or not is up to you :) |
p.s. Sorry for the whitespace noise on ReactMacro.hx. Visual Studio Code did that automatically and it's GIT diff viewer doesn't show whitespace changes so I didn't notice when I committed. I would love to get an automatic code-formatter for haxe to avoid noise like this :) |
Oh sorry, I should have re-read before commenting :P |
For returning strings/arrays it should just be allowed as return value for render. Though I wonder if it can be used anywhere a ReactElement is allowed. |
I'm doing some tests with
It seems to be available in most places where ReactElement is needed. It works for Maybe we need an intermediate typedef which we'd use where we know it is safe to use any of these types, instead of modifying ReactElement. Something like
Would work, except that we'd have to explicitly type our mixed arrays as |
Ew... At this point we may as well make it Dynamic :/ |
I really wish Haxe had a clean type for doing many In flow (which React itself uses) it would be something like I think confining the ugliness to a new type like:
or more realistically
is probably best for now. |
Just realised that's exactly what @kLabz suggested. Sorry for not reading properly! |
@@ -3,7 +3,7 @@ package react; | |||
/** | |||
https://facebook.github.io/react/docs/top-level-api.html#react.proptypes | |||
**/ | |||
@:jsRequire('react', 'PropTypes') | |||
@:jsRequire('prop-types') |
elsassph
Oct 2, 2017
Member
To make it right it should honor the -D react_global
flag:
#if (!react_global)
@:jsRequire("prop-types")
#end
@:native('PropTypes')
To make it right it should honor the -D react_global
flag:
#if (!react_global)
@:jsRequire("prop-types")
#end
@:native('PropTypes')
@jasononeil sorry another PR just merged introduced some conflicts - the good news is that the PropTypes change is done properly. |
Thanks @elsassph I'll resolve them and take a look. Sorry to have been a bit slow the last few days! |
React.hydrate()
ref
andkey
values in inline objects (previously were not included if undefined, now included asnull
). Essentially removing the-D react_monomorphic
option. In React 16, ifref
is undefined rather than null, you get a runtime error. See facebook/react#10649Fixes issue #78