Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Packager] Support for jsx filenames in React Native #2303
It seems that files with the extension .js can be required, but .jsx files cannot.
The following works fine:
var HelloPage = require("./src/views/screens/hello.js")
Restarting didn't seem to help. Is this a problem with something in React Native?
I want to name the files with JSX so that my editor uses the right syntax highlighter.
referenced this issue
Aug 12, 2015
This was referenced
Jan 9, 2016
pushed a commit
Jan 12, 2016
added a commit
Jan 20, 2016
added a commit
Dec 28, 2016
pushed a commit
Jan 26, 2017
After reading the comments on this issue, my opinion of the react-native team has changed drastically.
Like it or not, JSX is not vanilla JS and tools/editors/developers need to know what a file contains without parsing the entire content. Otherwise we might as well support only 1 file name as well.
I agree with the above that have a preference order is a good/safer solution. People are working around this issue with various atom/IDE changes, but your expectation as a react developer is the strongest naming convention is JSX is a JS file containing a React Component that is expressed using JSX (putting it out there..).
We are trying to support components in web/iOS/android, and because of this opinion to not support JSX extensions we end up having to drop jsx in our web naming to get a middle ground. This is not nice as suddenly we have an opinionated library forcing our standards. Our standard React and development coding standards are affected (including ESLint standards, such as using airbnb etc). The expectation is .jsx contains JSX, and a .js does not contain JSX.
It could be nice to be able to setup the following assumptions and have IDE/ESLint existing developer adopted standards happy;
If developers want to use .js, they still should be able to.
The webpack order priority works fine for developers and is flexible. I am assuming that the Packager has an order priority that is platform specific now (I should check..). Maybe you could have two priorities, that could have a default like: iOS: ['', '.ios.jsx', 'ios.js', '.jsx', '.js'] and then andriod ['', '.andriod.jsx', '.android.js', '.jsx', '.js'] for instance? It would bring uniformity to peoples projects and restore the balance of the universe ;-) It seems like an ideal goal? Even better as a second step to make it configurable, but just getting support in there would be beneficial to start.
I can appreciate there are some challenges and probably ones I haven't presented here, but these are not uncommon challenges that we've had to deal with in developing with React in the first place. I think the citing of the comment about 'what happens when you define a .js and a .jsx' being confusing is valid, but only to a degree. I would have thought we've all had to deal with that as React developers.
The whole React IDE/Ecosystem (ESLint etc) are generally geared towards supporting .jsx has JSX as the convention. Developers have to embrace their decisions around conventions and believe in them, because it does allow us all to work together better, and generally gets annoying if you create rules outside current convention.
If this is going to be the case, could you get something added to the documentation that clarifies that filenames can't be .jsx. I just spent a couple hours trying to figure out why my module couldn't be found only to discover that React Native doesn't support the .jsx extension that is common for React projects. Maybe a section on React Native differences from React would be a good place for this as well as other differences between the two projects.
We can't figure out how to give priority of the files, seriously, that is the argument. Just pick one, our responsibility is to know how that works and pay attention, you do not need to be the Protector of all the programmers. Either
Here is the thing, JSX was invented by Facebook for React.
Yes, you are right, today we can even put
I can take my
Those extensions have nothing to do with specific framework (React). So what is the point of your argument because I am not following.
JSX was invented strictly for React 4 years ago (Preact now and any other VDOM syntactic sugar)
So again, what is your point?
Support more random extensions, yes, you are right.
But let's forget 4+ years of React development and let's call it now
The reason that code style like AirBnB exists and force engineers to use
@MindFreeze your argument is exactly what make me questioning the argument from @vjeux , JSX was invented
But again, I think that this is a lost battle, you can give them as many arguments as possible and they will no listen, what other argument could you give when
I hope I am wrong about it, but time will let us know if React Native project is run by dictator or leaders (the core difference, the first one dictate how things work no matter what and the second listen) I hope at least to get some strong responses because so far is one person vs everyone else (even the core that let the feature to get into the package and then remove, sign)
This doesn't make any sense... As said before, Facebook invented
I have a React project with lots of components using the
The nice thing about having different extensions is that when I look at a file I can deduce the following from its extension:
When it comes to