Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for custom JSX pragmas #210

Merged
merged 1 commit into from
May 20, 2018
Merged

Conversation

alangpierce
Copy link
Owner

Fixes #207

As with Babel, we assume the pragma is a dot-separated list of identifiers (or
just an identifier), which we parse so that we can replace the base name if
necessary.

Fixes #207

As with Babel, we assume the pragma is a dot-separated list of identifiers (or
just an identifier), which we parse so that we can replace the base name if
necessary.
@alangpierce alangpierce merged commit 25e06ca into master May 20, 2018
@alangpierce alangpierce deleted the support-jsx-pragmas branch May 20, 2018 01:58
@StreetStrider
Copy link

Hello. Is pragma comment supported?

@alangpierce
Copy link
Owner Author

@StreetStrider No, not at the moment. I just filed #479 to track the issue. What's your use case, out of curiosity? Do you have a codebase where different files need different JSX behavior?

@StreetStrider
Copy link

@alangpierce I haven't got specific use-case right now, I'm learning things here. I just previously knew that jsx pragma is a valid way to setup a vdom constructor. I'm not sure about real user base, but if there is such a way, this pragma will occur in real world JSX.

I think my future use-case would be so: explicitly use jsx pragma comment in every file and explicitly import corresponding vdom constructor. It is explicit and does not depend on external config of any kind. However, this is a still thing to investigate for me.

@alangpierce
Copy link
Owner Author

@StreetStrider Makes sense. Yeah, JSX is a bit awkward in that it started out as a React thing and was made more general, so you need custom configuration (or pragma comments) to configure the transpile output. Seems like a roadblock making it even less likely that it'll eventually get native browser support.

I think in practice it tends to happen for projects using two different UI frameworks, e.g. a project that's in a transition between React and Vue. But it's true that pragma comments have the nice aspect of making code more universal and less reliant on external config.

@StreetStrider
Copy link

@alangpierce I will be notified here. However, if this feature is too complex for Sucrase, I'm OK if it will not be implemented.
I'm attracted by simplicity of Sucrase's usage. Right now I'm using tsc + noEmit to typecheck + Sucrase to cut TypeScript syntax (previously, same for Flow). So, I'm always produce JS with Rollup + plugin infrastructure; I find that is a robust approach (I'm not using tsc for bundling, or Babel, or anything else — it's always Rollup, so I can freely reuse configs, plugins and knowledge).

Hopefully, JSX can be resolved in Sucrase, but if not, I will investigate rollup-plugin-jsx as a second step. I'm pretty sure it supports all the features, but involves Babel internally as a drawback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Suggestion: drop dependency on React.createElement
2 participants