Change JSX output from React to SolidJs?

61

Sorry that comment was not very serious. In general when 2 programs have the same semantics, you would like to be able to rewrite the first into the second. It seems that is not true with solidjs. And there is probably a good reason for that. Just, the fact stands that it does not respect semantics.

1 Like
62

Even with proxies. The following two functions are equivalent in JavaScript but not in Solid:

function A(proxy) {
  let x = proxy.x
  return <div>{x}</div>
}

function B(proxy) {
  return <div>{proxy.x}</div>
}
2 Likes
63

Now your point its clearer, but I still think you are looking at the wrong semantics. Solidjs uses proxies, and proxies semantics dictates that you donā€™t detach properties from proxies if you want to keep accessing them through the proxy interface. The problem here lies with fact that you are applying object semantics to something that are not objects. They may look like objects, and behave almost like objects, but there are subtle differences that you can not ignore.

1 Like
64

Thatā€™s not true. In the first example you are extracting the value through the proxy get method, then you use it, in the second case youā€™re executing the get method every time you run that JSX. Iā€™m on mobile, but put the returned Jax in a thunk and you will clearly see the difference

1 Like
65

This is probably the key. The semantics of JSX is different in Solid.

Traditionally JSX is an immutable data structure. It has the same semantics as a json object. I think you wouldnā€™t argue that the following arenā€™t equivalent:

function A(proxy) {
  let x = proxy.x
  return {children: x}
}

function B(proxy) {
  return {children: proxy.x}
}

Solid changes the semantics of JSX, which is not as bad as changing the semantics of JavaScript, but still confusing for the people who are used to different and arguably more common meaning of JSX.

66

I find it interesting that in Solid you can do

function foo() {
  let divRef;
  return <div ref={divRef}/>;
}

so you donā€™t submit the value of divRef to the JSX term (itā€™s undefined) but only its name. This seems radically different from React, where divRef has the .current property, so itā€™s never without value, if that makes sense. TS also grapples with this sometimes, but you can help it out by writing ref={(el) => divRef = el}.

1 Like
67

Holy magic :scream: It doesnā€™t make any sense in JavaScript world

5 Likes
68

I donā€™t like where this discussion is heading. In my opinion solid is a great library that does many things right. Choosing to support JSX is one example. This is also one of the reasons I was attracted to ReScript right from the beginning (Besides the awesome fact that itā€™s a functional language). Building your components in JSX just feels right to me.

Yes, solid is certainly doing some things differently than people using react (or even ReScript) are used to. But that doesnā€™t mean they do it in the wrong way.
For example there is no such thing as wrong JSX semantics. JSX, per definition, has no semantics.

JSX is an XML-like syntax extension to ECMAScript without any defined semantics.

See: JSX Spec

For me the question is not about right and wrong, better or worse. Itā€™s about the philosophy and guiding principles behind ReScript and solid. While, from my perspective, I would love to see those two work seamlessly together (because I think they are a nice fit), there definitely is a gap to be closed.

So the only questions remaining for me are: Is sensible to close the gap? How much effort would it be? And is it worth it?

Since Iā€™m pretty new to ReScript, I donā€™t feel qualified to answer the first and second question. Perhaps the differences are so fundamental that it would be against the spirit of ReScript to bend it in that direction. And this is not only about solid. Itā€™s more about supporting additional JS features like object proxies etc.
Or, with a little thought, solid would fit right in.

And the third question is not easy to answer either, since it also depends on the community. If there are many people out there, that would love to use both together, it could be good thing. But if we are only a tiny minority, the effort might be wasted.

I personally am quite happy right now, using the babel preset. It works well enough for me and the small apps Iā€™m building with it. And Iā€™m reasonably confident that it will also work with future versions of ReScript (albeit with a few adjustments).

Sorry for the long post :face_with_hand_over_mouth: .

6 Likes
69

I think one needs to experiment before hoping to insert the solid idiosyncrasies inside the JSX ppx.
My suggestion is to wait until JSX V4 is out, see what its output looks like, and experiment with it.
The generated code is simple enough that one can just write the generated code directly without using the ppx.
That way weā€™ll know for sure what does and does not work.

It could just be that solid is not compatible with having a compiler in the toolchain other than itself. A compiler by definition turns some code into some other code, and has its notion of semantics.
Or maybe only some small adjustments are needed.

Only, one step at the time. One cannot expect the upcoming JSX 4 to conform to solidā€™s specific rules before itā€™s even out. That would only delay V4 before we even know what level of support is actually possible.

10 Likes