Open myitcv opened 7 years ago
When you say the runtime behaviour is different, does it mean that some code could run correctly (i.e. as intended) with the dev version, but not with the prod version?
If that can't happen, I don't really see the runtime difference being a negative.
When you say the runtime behaviour is different, does it mean that some code could run correctly (i.e. as intended) with the dev version, but not with the prod version?
The React team or docs would be the definitive answer on this.
But I raise the question here really because really there should be no difference between development and production; it's tantamount to having a -test
flag where your code behaves different in one "environment" vs another. It's something that Rob Pike rightly, in my opinion, calls out as bad practice.
But in this situation, as I mentioned in the description, I think the situation is slightly different. Because good static analysis is very hard, the option of the development vs production version is more akin to the -race
mode of the Go toolset. So I can see that it has merit (particularly if you consider an app that combines GopherJS React code with other non-GopherJS React components)
So really an opportunity to opine on these various points.
Related to #28 but not dependent on it; this issue is relevant so long as
github.com/myitcv/gopherjs/react
continues to offer the option of bundling React's.js
filesPicking up on discussion in https://github.com/gopherjs/gopherjs/issues/611, specifically from this comment
Facebook have two versions of the React
.js
files:The development version is somewhat analogous in my mind to the race detector mode of the Go toolchain.
We currently (as of f51106b7ade5da288a9b798bb6c700d59032b0a0) bundle the prod version by default; the development version is enabled via
--tags debug
.As the Facebook docs make clear, the runtime behaviour of these two versions is different.
The question is: should we provide the option of bundling one vs the other?
Points to consider:
<p>
elements)