Comments (7)
I also run into this issue, so add a +1 here to renaming source files to .jsx. This doesn't only affect react-select, but also to its react-input-autosize dependency.
For the time being, you can special-case the library in webpack this way:
module.exports = {
// ...other webpack config
module: {
loaders: [
// ...other loaders
{
test: /\.js$/,
include: path.join(__dirname, 'node_modules', 'react-select'),
loader: 'jsx-loader',
},
],
},
};
from react-select.
Sorry to take to long to respond to this @yonatanmn and @julen.
Would it solve the issue if we added the /* @jsx React.DOM */
header back in?
from react-select.
I'm afraid the header doesn't solve the issue, plus it's unnecessary starting from 0.12 (I guess the OP was on React <0.12).
As a dev I don't like the idea of processing non-JSX files through the jsx-loader — it's superfluous. Special-casing for a library sucks too (see the workaround described above). As mentioned earlier, the natural solution for me is renaming the source files to .jsx, as these contain JSX code. If they're kept in .js, I'd expect them to be plain React with no JSX syntax.
from react-select.
@julen I thought maybe Webpack could be configured to process files with the JSX header, even though it's no longer necessary. Sound like that's not a thing.
The reason I don't like renaming the files to .jsx
is that I don't start files thinking about whether or not I'll use JSX in them, I just use it where it makes the code I'm writing clearer. I think about it the same way I decide between using array.forEach
vs. a for (...)
loop.
I appreciate not having to stop and think "oh wait, this is now a different type of file" and renaming it. And sometimes I refactor JSX out of files too - which would then be the opposite. I don't want to call files without JSX In them .jsx
and it doesn't seem clean to have half the logic of an app in files that have different extensions, when it's really the same language*
, and it's all going through a single build process anyway (either via webpack or browserify).
If they're kept in .js, I'd expect them to be plain React with no JSX syntax.
Sure, what about ES6 code though? I'm looking at using 6to5 for some projects too, by the same logic I should name a .js
file differently if I was using ES6 features that needed transpiling.
I'm not having a go, I just publish a lot of code across a lot of projects and if I make this change, I'll make it everywhere for consistency and I'm taking the time to think about whether it's the right long-term approach.
I can understand you don't like processing non-JSX files with the jsx loader, and I agree the special-casing really does suck. I want this component to be as easy to drop into your project as possible, regardless of your build process or other packages.
Hopefully we'll come up with some good answers in #40, and I'll get it cleaned up soon.
*
I've considered the similarity between this and naming template files with their language (e.g. .hbs
) when they're primarily HTML; however in that case, you're processing one language (handlebars) to generate another (HTML) which is interpreted very differently, so they're actually distinct. In the case of JSX it's really just a different syntax; you're still writing Javascript and it's still executed once as javascript - it just needs to be expanded first.
The other counter example here would be coffee script files with the .coffee
extension, which are executed as Javascript, however those files are a completely different syntax, and you aren't just interspersing a shorthand syntax in what is primarily just Javascript.
from react-select.
It's appreciated the time you've taken to think about this and your determination to address the problem generally, so it gets fixed once and for all across your other libs.
I believe the angle we're focusing this issue is not completely right for library consumers, although the points you're raising are very valid for the library developers. In the end, users shouldn't care about the file extension or build tool you have chosen when developing the library.
As mentioned in #35, there wouldn't be a need for consumers to process react-select through a JSX transform step (or any other transforms such as 6to5).
Having said that, I'd close this issue in favor of #35 and #40. Hopefully we can soon offer a solution that works for everyone.
from react-select.
In the end, users shouldn't care about the file extension or build tool you have chosen when developing the library.
Agreed. We'll get there.
from react-select.
lib
files no longer contain JSX and the src files are only referred to in the build process, so this issue is fixed now.
from react-select.
Related Issues (20)
- worst thing ever see in my life HOT 2
- Types broken in `React@19` & `Next@15` HOT 4
- CreatableSelect missing all classes HOT 1
- Page crashed in Edge browser with translation
- Clicking outside of the menu does not close a controlled menu
- Unable to select color using voice access commands.
- Async Select Multi: Options Cleared After Selection Despite Persistent Search Term
- how to get the value from select component in a form based on id
- Tooltip not working
- AsyncCreatableSelect not allowing to enter more than character to search or create
- defaultValue text gets truncated with elipsis (...) at the end HOT 1
- how to avoid this select expand while selecting multiple options
- Unexpected behaviour in combination with `react-hook-form` HOT 1
- Select not scrolling to Selected Item when menuPortalTarget={document.body}
- Incorrect user of <label for=FORM_ELEMENT>
- Pressing enter on a button in a custom option component consumes the event before it reaches the custom button. HOT 1
- Tabindex not working HOT 2
- The dropdown does not open in createable select when the search input and the options label do not match
- Clicking on an item using Custom Menu scrolls to top HOT 1
- Styles not Loading in Remix HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react-select.