POJO Elements #37

iddan · 2018-03-29T00:03:49Z

JSX will be transpiled to object literals, native types to factory functions.

facebook-github-bot · 2018-03-29T00:04:04Z

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

facebook-github-bot · 2018-03-29T00:08:59Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

streamich · 2018-03-29T00:15:13Z

text/0035-pojo-elements.md

+
+### Security
+
+Unlike in previous discussion this proposal is secure because **type is always a function**.


What about custom elements, how will they be transpiled?

<my-custom-element />

Should be added to questions. Any ideas?

streamich · 2018-03-29T00:16:58Z

text/0035-pojo-elements.md

+  props: {
+    children: "Hello, World!"
+  }
+}


Why not use JSON-ML:

['div', {}, 'Hello, World!']

Readability and consistency, but totally an option.

@streamich what is that JSON-ML? His example is just JSON, what are the benefits of JSON-ML?

It’s a more compact in code and memory format

It’s a standard for describing XML like data structures in JSON

streamich · 2018-03-29T00:20:51Z

text/0035-pojo-elements.md

+
+# Motivation
+
+ - No more JSX pragma: React-like libraries like Preact would be able to consume React components with **no synthetic syntax modifications**. Of course there can be many other differences but there is enough common ground that worths the changes in my opinion.


To make other libraries consume JSX, like

<div>Hello world</div>

one could make JSX transpiler emit closures with hyperscript function h dependecy injected:

(h) => h('div', {}, 'Hello world');

jquense · 2018-03-29T01:03:44Z

text/0035-pojo-elements.md

+
+# Motivation
+
+ - No more JSX pragma: React-like libraries like Preact would be able to consume React components with **no synthetic syntax modifications**. Of course there can be many other differences but there is enough common ground that worths the changes in my opinion.


it seems like you wouldn't avoid the pragma, since the compiled-to type ReactDOM.div is library specific. Wouldn't this have the same coupling as createElement?

Well no, because anything not interacting directly with DOM elements or allows providing replacement components will benefit from this change. Anyway Preact uses class and React uses className and there are other small differences but many components will still be able to target both

jquense · 2018-03-29T01:04:49Z

text/0035-pojo-elements.md

+Unlike in previous discussion this proposal is secure because **type is always a function**.
+Unlike strings a function can't be injected by XSS or similar. If a JSON will be parsed type will remain string and will be considered an error:
+```json
+{ "type": "div", "props": { "children": "Hello, World!" } }


how will a consumer of the element be able to determine if the type is a host type or a composite type? At the moment one can do isHost = typeof element.type === 'string'

isHost = element.type instanceof ReactDOM.Element

dantman · 2018-03-29T01:18:32Z

Currently one of createElement's jobs is to emit dev mode warnings when a ref or key is invalid. To my knowledge this is done in a function call instead of afterwards based on the POJO because afterwards we don't know where the source of the error was and it makes debugging harder. facebook/react#3228

It also freezes things, adds _self, _source, adds warning getters for ref/key, etc... to help with debugging. And it handles defaultProps too.
https://github.com/facebook/react/blob/master/packages/react/src/ReactElement.js#L110-L257

dantman · 2018-03-29T01:31:23Z

This will also hinder minification:

React.createElement('div', {}, 'Hello, World!') can be reduced to a.createElement("div",{},"Hello, World!")
If we transform React.createElement to createElement then createElement('div', {}, 'Hello, World!') can be simplified to a("div",{},"Hello, World!")
Unless you enable really advanced (and scary to most people) key mangling, {type: ReactDOM.div, props: { children: "Hello, World!" } } can only ever be simplified to {type:a.div,props:{children:"Hello, World!"}}

The props, children, and types keys can never be optimized away and make the code larger when minified. And JSX is used a lot in general making space wasting syntax in the JSX transform output grow exponentially.

thysultan · 2018-03-29T01:44:31Z

text/0035-pojo-elements.md

+
+# Motivation
+
+ - No more JSX pragma: React-like libraries like Preact would be able to consume React components with **no synthetic syntax modifications**. Of course there can be many other differences but there is enough common ground that worths the changes in my opinion.


From a performance and compostability perspective, the current semantics allows react and react-like libs to have more control of the resulting data-structure created between patch/minor sem-versions, this would go against that, forcing them to conform to consume what ever data-structure is agreed upon within the reconcile phase.

When considering that these libs add meta data to the snapshot data-structures, this would effectively kill the monomorphic nature that one has control over with the current pragma composition pattern since there would still be a need to add lib specific meta data. i.e Inferno emits it's own meta data for performance reasons, Vue emits it's own meta data as does DIO and i'm sure Mithril, Preact and other reactive libs that emit a primitive snapshot structure include specific meta data for their needs in addition to the normalization each libs undertakes to flatten children.

I see React as more than just a library but an ecosystem and reference for other libraries. This proposal suggests a trade off a custom element instanciation for standard data structure to represent the virtual DOM

j-f1 · 2018-03-29T01:45:25Z

Comparison:

// numbers are how many characters shorter
a.createElement("div",{},"Hello, World!")//34 (4 ch)
a("div",{},"Hello, World!")//3456789012345678 (18ch / 14ch)
{type:a.div,props:{children:"Hello, World!"}}

iddan · 2018-03-29T08:37:40Z

If following @streamich proposal JSON ML syntax would actually reduce compiles code size.

streamich · 2018-03-29T09:56:34Z

@iddan Here JSON-ML is discussed:

Consider Using JsonML as Notation for ReactElement facebook/react#2932

trueadm · 2018-03-29T10:33:34Z

There's a few things I want to point out here:

As others have already mentioned, we use React.createElement() to do far more than just create "virtual nodes", they are used for dev-time related checks and validation.
We also handle things like "key" and "ref" that are special cases and require runtime logic to make this work. Take for example <MyComponent {...stuff} />, if stuff contains key or ref, we need to extract those from the props – something we can't do statically if we don't know if either property exists.
We use a $$typeof property on ReactElement to understand what type of element it is, for this we use an internal system of symbols to ensure we're dealing with something that was created via React. We'd still need this system, we can't simply use the type property here because it would get far too overloaded.
In terms of performance, I've found that using a lightweight monomorphic function to create a monomorphic resulted in better performance than creating polymorphic inline objects – because as already mentioned, the hidden classes won't match if you adopt the proposal. To ensure the objects are monomorphic, we'd need to ensure that both ref and key are added to every ReactElement POJO, even if they are not used (they would be set to null).
There's far too much focus on JSX -> virtual DOM here. That might be what JSX de-sugars to now, but in the future I expect we'll make compile time optimizations in React and move away from virtual DOM entirely.

I'm not too sure this RFC brings any benefits to React or its ecosystem.

streamich · 2018-03-29T10:36:44Z

...and move away from virtual DOM entirely.

Interesting.

bvaughn · 2018-05-07T18:26:45Z

text/0035-pojo-elements.md

+
+### Security
+
+Unlike in previous discussion this proposal is secure because **type is always a function**.


Perhaps I'm misunderstanding this statement, but type isn't always a function. For example:

React.forwardRef, Context.Provider, and Context.Consumer are objects

React.StrictMode and React.AsyncMode are symbols

Many React Native host types (e.g. View) are strings

This proposal seems very ReactDOM-centric.

The problem is only with bare strings. So as long as type is an object, symbol or function there is no problem.

Many React Native host types (e.g. View) are strings

bvaughn · 2018-05-07T18:27:53Z

text/0035-pojo-elements.md

+  props: {
+    children: "Hello, World!"
+  }
+}


What happens to key and ref attributes? Although not relevant to this specific example, these are important. Moving them into props would be a pretty big backwards breaking change (because of e.g. {...props}).

They are practically props aren't they today? What mechanisms differentiate them?

They aren't props. They're stored separately on ReactElement. If they were in the props argument, then spreading props (e.g. <Foo bar="abc" {...props} />) would pass ref and key too. Particularly with refs, this could cause a problem, as it could result in the same ref callback being called for many types of element.

Edit Just noticed @trueadm's comment also touches on this.

Current behaviour:

const React = require('React'); const el = <div b='c' ref={() => {}} key='key' />; el.props.b; // 'c' el.props.ref; // undefined el.props.key; // undefined

iddan · 2018-05-07T22:00:36Z

@trueadm I don't think this proposal has anything to do with the virtual DOM actually. This is a proposal to represent JSX in a more generic and native JS way.

sebmarkbage · 2019-03-02T06:50:35Z

I think any proposal like this would like want an intermediate upgrade path in the ecosystem using something like #107 regardless.

After that the question is basically if it should be a function call or inline. All our testing suggest that a function call is the way to go in this case because it allows the VMs to dedupe a lot of the code gen that happens for each of these callsites. So it'd probably end up being a function for that reason. It could in theory be a built-in function in the transpiler runtime rather than on React though. That's covered in #107 too though.

iddan · 2019-03-02T10:20:56Z

@sebmarkbage Can you elaborate

All our testing suggest that a function call is the way to go in this case because it allows the VMs to dedupe a lot of the code gen that happens for each of these callsites. So it'd probably end up being a function for that reason.

Create 0035-pojo-elements.md

45f9c23

facebook-github-bot added the CLA Signed label Mar 29, 2018

streamich reviewed Mar 29, 2018

View reviewed changes

jquense reviewed Mar 29, 2018

View reviewed changes

thysultan reviewed Mar 29, 2018

View reviewed changes

bvaughn reviewed May 7, 2018

View reviewed changes

iddan closed this Apr 1, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

POJO Elements #37

POJO Elements #37

iddan commented Mar 29, 2018 •

edited

Loading

facebook-github-bot commented Mar 29, 2018

facebook-github-bot commented Mar 29, 2018

streamich Mar 29, 2018 •

edited

Loading

iddan Mar 29, 2018

streamich Mar 29, 2018

iddan Mar 29, 2018

yordis Mar 29, 2018 •

edited

Loading

iddan Mar 29, 2018

streamich Mar 29, 2018

jquense Mar 29, 2018

iddan Mar 29, 2018

jquense Mar 29, 2018

iddan Mar 29, 2018

dantman commented Mar 29, 2018

dantman commented Mar 29, 2018

thysultan Mar 29, 2018 •

edited

Loading

iddan Mar 29, 2018

j-f1 commented Mar 29, 2018

iddan commented Mar 29, 2018

streamich commented Mar 29, 2018

trueadm commented Mar 29, 2018 •

edited

Loading

streamich commented Mar 29, 2018

bvaughn May 7, 2018

iddan May 7, 2018

bvaughn May 7, 2018

bvaughn May 7, 2018

iddan May 7, 2018

bvaughn May 7, 2018 •

edited

Loading

dantman May 7, 2018

iddan commented May 7, 2018

sebmarkbage commented Mar 2, 2019

iddan commented Mar 2, 2019


		### Security

		Unlike in previous discussion this proposal is secure because type is always a function.


		# Motivation

		- No more JSX pragma: React-like libraries like Preact would be able to consume React components with no synthetic syntax modifications. Of course there can be many other differences but there is enough common ground that worths the changes in my opinion.

POJO Elements #37

POJO Elements #37

Conversation

iddan commented Mar 29, 2018 • edited Loading

facebook-github-bot commented Mar 29, 2018

facebook-github-bot commented Mar 29, 2018

streamich Mar 29, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yordis Mar 29, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dantman commented Mar 29, 2018

dantman commented Mar 29, 2018

thysultan Mar 29, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

j-f1 commented Mar 29, 2018

iddan commented Mar 29, 2018

streamich commented Mar 29, 2018

trueadm commented Mar 29, 2018 • edited Loading

streamich commented Mar 29, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn May 7, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iddan commented May 7, 2018

sebmarkbage commented Mar 2, 2019

iddan commented Mar 2, 2019

iddan commented Mar 29, 2018 •

edited

Loading

streamich Mar 29, 2018 •

edited

Loading

yordis Mar 29, 2018 •

edited

Loading

thysultan Mar 29, 2018 •

edited

Loading

trueadm commented Mar 29, 2018 •

edited

Loading

bvaughn May 7, 2018 •

edited

Loading