Allow internal components to be used in the browser version

[totty90]

I'm using flux and I need the 'react/lib/copyProperties'. This is easy with browserify var copyProperties = require('react/lib/copyProperties'); but with require.js is not possible because it uses the bower version which doesn't contain the copyProperties fn (https://github.com/facebook/react/blob/aae31ae24c67216894ae42b8481a599206d18690/src/browser/ui/React.js). Would be nice to have them like this React.lib.copyProperties()

Maybe include all the lib components.

Is this possible?
Thanks

[syranide]

This would affect minification and it's an internal API that's subject to change at any time. If you want a function, use your own copy I'd say. (PS. Also use webpack instead of require.js :))

[totty90]

But in browserify with npm you can use them, isn't that coherent? Just because is bower I can't use it?
Maybe an internal API would be enough, even if changes. I know the functions are in the minified version, so you just have to export them somehow.

[syranide]

@totty90 "can" and "should" are two different things. They're not publicly exposed, by reaching into react/* you are accessing internal modules, React offers no guarantees.

[totty90]

@syranide Look at your flux example:

https://github.com/facebook/flux/blob/master/examples/flux-chat/js/stores/MessageStore.js

var merge = require('react/lib/merge');

https://github.com/facebook/flux/blob/master/examples/flux-chat/js/constants/ChatConstants.js

var keyMirror = require('react/lib/keyMirror');

So, you are only giving the benefits to the npm version, while hiding from the bower version. Would be better if both would have the same structure. In this way if someone goes from npm to bowser version doesn't have to change all the stuff.

• You provide a tutorial that uses internal stuff, but then you say is internal and should not be used?
• I think internals should also have "_" prepended at least to be understood that are internals, because those seems public.

Is your decision whenever to add it or not, but if you decide to don't add it, then please notice the flux guys to make a tutorial with the API modules instead of the internal ones. You say "do this like that, but you shouldn't" or in our context "use require('react/lib/keyMirror'), but don't use internal API".

[syranide]

I'm not an official dev so that's not my decision. I imagine that it was simply with the intent of keeping the meat of the examples simple rather than having link to all the different implementations.

It's not React's purpose and it's rather arbitrary; what should be exposed and what shouldn't. Should helpers not useful to React but users also be exposed? Should library X also expose merge, which one should you use? What if React no longer needs merge? What if React suddenly requires a specific semantic implementation of merge?

I think the idea that React should expose helper methods is flawed, if anything, it should probably be the other way around. React should depend on shared modules, if you depend on the same module and your dependency requirements are compatible you would share the implementation.

Again I'm not on "Team React" so this is not my decision.

[totty90]

Yes, this seems a better approach. I also thought about the problem when react does't need a lib anymore.

[syranide]

@totty90 This is not my responsibility, but if you want to submit an issue to petition for moving share-able utils from core into separate packages then that seems sound to me (not that I would expect it to happen anytime soon).

[syranide]

Apparently it's "kind of" happening #2317

[zpao]

Not going to do this. trying to move away from this as much as possible. Flux examples should probably not use the internal modules.

[zpao]

Filed facebookarchive/flux#77 for Flux.