how can i mix 2 JSX framework in the same project?

my client uses React, my server uses homemade JSX factory, React JSX definitions mess up server JSX definitions, is there a way of not making them global so they don't see each other?

a working example of a setup of a project with React + other JSX would be much appreciated

is there a way of not making them global so they don't see each other

No. JSX type is looked up globally. Similarly the emitter for JSX is global reactNamespace e.g. if instead of using React you are using Th, your config would look like : https://github.com/typehtml/typehtml/blob/2af41218f93e836ced283d373fc10a396f7d1d46/tsconfig.json#L3-L4 🌹

André Staltz (@staltz)

Adding André Staltz (@staltz) for cycleJS https://github.com/cyclejs/cyclejs as he might have ideas ❤️

at the compile time i can separate them by excluding/including only the right files, but what's extremely annoying is that at design time (when i am coding) my experience depends on which file server-jsx.d.ts or client-jsx.d.ts gets loaded to IDE first, so it's either the client code all messed up or the server one

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) what is the rationale for JSX to be looked for in a global namespace? i wish i could do it like this:

import * as custom from 'custom/jsx';
import JSX = custom.JSX;
// ...

what is the rationale for JSX to be looked for in a global namespace? i wish i could do it like this:

normally you would not import JSX, it has no runtime impact. you would import react or some other library.

at the compile time i can separate them by excluding/including only the right files, but what's extremely annoying is that at design time (when i am coding) my experience depends on which file server-jsx.d.ts or client-jsx.d.ts gets loaded to IDE first, so it's either the client code all messed up or the server one

Why is it that you do not have two tsconfig.json files?

Why is it that you do not have two tsconfig.json files?

I have 2 config files, but it only helps when I compile, not when I am developing. There is no problem with compiling the client and the server code separately. There is a problem when you develop the code for the entire application with interconnected parts.

The client and the server come very close as you work on a feature, for example: the client needs some data from the server being passed over a piece of HTML/JS markup. So you need to make sure the client is expecting it at the same place where the server is going to provide it. So ideally you want to check through a full-text-search within the same set of files that there are 2 places: one at the supplier side (server) and one at the receiver side (client) that match. If I separate this into 2 differnt projects (one for the client and one for the server) it's twice as much work:

get a search ready
open the client
do the search
make sure you found it
open the server
do the search
make sure you found it

And what I want instead is:

do the search
make sure you found it in client
make sure you found it in server

Is my point clear?

Again, in order to be able to oversee my both client and server within the same set of files, all I need it that 2 different JSX played nice with each other.

I feel like this is more general. It would be very useful to be able to specify that, at runtime, a non-relative import maps to different dependencies depending on the location of the importing module. If that were possible then this might well be resolvable via declare global.

This is a pain point for me as well. I need two separate projects with two tsconfig.json files and I can't even require() files between them even though they are one program / process for me.

Babel let me override the "jsxFactory" in a .babelrc for a subdirectory (or even a single file with a comment) without it being a separate project (though, babel doesn't really have a 'project'...)

What you can do is importing 'fake' react object that have createElement method.

eg
fileWithCutomJSX.ts

import React from './fakeReact.ts'

const jsxFromCustomFactory = (<div />);

fakeReact.ts

const fakeReact = {
  createElement: (...args) => {...args};
}
export default fakeReact;

As jsx factory in tsconfig.json is React.createElement - it'd use your 'fake' one in scope of single file that has imported it.

It'll work but I think there should be some 'core' solution for that in TS.

Also it'll propably cause some ts complains about wrong types as TS JSX is quite strongly tied with React JSX sadly.

I think JSX be treated in more general way where JSX is treated as data structure, not some specific use case od that like DOM element.

I also it would unlock many potential great useages of JSX as JSX is great for defining complex structures of any data.

just faking the factoring isn't enough

problem is that JSX namespace is global (ambient) so its definition is always the same to all files in the project, whereas what's needed is that different files have different JSX definitions within the same project

Aleksey-Bykov

Aleksey-Bykov this seems related as well #11917

This remains a huge issue for us. We have a complex set of packages that are assembled in to different top level applications. Each of those packages may need a different JSX namespace. Is there a benefit to having that namespace be global and not per module?

Random update: We provided a fix for this a few releases ago (TS 2.8). You can specify a non-global JSX namespace within the same namespace as the factory function, and a per-file factory function using an @jsx pragma comment, similar to babel.

Navigation Menu

Repository navigation

how can i mix 2 JSX framework in the same project? #15386

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

how can i mix 2 JSX framework in the same project? #15386

Description

Activity

basarat commented on Apr 26, 2017

basarat commented on Apr 26, 2017

zpdDG4gta8XKpMCd commented on Apr 26, 2017

zpdDG4gta8XKpMCd commented on Apr 26, 2017

mhegazy commented on Apr 26, 2017

zpdDG4gta8XKpMCd commented on Apr 26, 2017

aluanhaddad commented on Apr 27, 2017

luggage66 commented on Apr 28, 2017

pie6k commented on Jun 13, 2017

zpdDG4gta8XKpMCd commented on Jun 13, 2017

aluanhaddad commented on Jun 29, 2017

ellisonbg commented on Jun 30, 2017

weswigham commented on Oct 26, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions