Explore defining UIDL in hyperscript instead of JSON

[vladnicula]

What's wrong with JSON

• Reading the JSON definition of components is quite hard for humans.
• Adding, altering and changing the UIDL is hard for humans and prone to errors.
• We have UIDL validation issues and need to improve validation by a lot as seen in Extend the UIDL validator with business rules #41 and Missing/ Mispelling a state key crashes the component generation #145
• We are already starting to build hyperscript like functions to build our definitions in the tests (like we do here)

What's good with hyperscript

• It's easier for humans to read, edit and create UIDL content
• It could look like JSX
• We could have in-place typescript syntax checking just like JSX tags in react OR we could have in-place typescript checking for the hyperscript function.

Let's compare the declaration of a component

{
"LandingContainer": {
      "propDefinitions": {
        "landingImage": {
          "defaultValue": "url(static/landing-photo.jpg)",
          "type": "string"
        }
      },
      "name": "LandingContainer",
      "node": {
        "type": "element",
        "content": {
          "elementType": "container",
          "style": {
            "backgroundImage": { 
              "type": "dynamic", 
              "content": { "referenceType": "prop", "id": "landingImage" } 
            },

            "backgroundSize": { "type": "static", "content": "cover" },
            "backgroundColor": { "type": "static", "content": "#232323" },
            "backgroundPosition": { "type": "static", "content": "center center" },


            "width": { "type": "static", "content": "100%" },
            "height": { "type": "static", "content": "100vh" },

            "display": { "type": "static", "content": "flex" },
            "alignItems": { "type": "static", "content": "center" },
            "justifyContent": { "type": "static", "content": "center" }
          },
          "children": [{
            "type": "dynamic",
            "content": {
              "referenceType": "prop",
              "id": "children"
            }
          }]
        }
      }
    }
}

An equivalent JSX like syntax would be:

<Element name='LandingContainer' type='container'>
   <Definitions>
       <Prop name='landingImage' type='string' default='url(static/landing-photo.jpg)'/>
   </Definitions>
   <Element type='container'>
      <Style>
            {{
               width: "100%",
               backgroundImage: <PropValue of='landingImage'/>
            }}
       </Style>
       <Slot/> {{ /* basically props.children, the main default slot for vue or web components */ }}
   </Element>
<Element>

[JayaKrishnaNamburu]

Hi @vladnicula that's a awesome idea when we consider the use case in which targeted audience as users, but i feel is, if a user is writing something in JSX they can directly write a react component / vue respectively, But when we consider the use case of project this helps a lot.

But how many will actually adopt this style of writing a project because they can get the end result in many flavours as a result 🤔

When we consider the use case of wireframes to project export this is amazing the ability to download any flavour of codebase 🌟

Currently we can how about we set few values as default in generators like if the user forget's to mentions type static by default we pick it is as static in that way users don't need to write a good number of lines of JSON instead they can mention in only few cases like dynamic

How about we build something like eslint-teleport-schema which helps in hi-lighting the errors in the playground and see how users adopt to the learning curve and then we can visit this again and re-consider adopting hyperscript.

(I am not sure how complex is the process of moving from a Schema to hyperscript 😅 )

[vladnicula]

@JayaKrishnaNamburu I understand your point of view and share the idea that writing tags should not be the only way of writing things, however it's much easier for me to "build" the UIDL JSON by writing tags like the ones mentioned before. I also believe that defaulting some keys in the UIDL is not enough to make the project/document readable.

So no no, I don't suggest we move the UIDL schema from JSON Schema Definition to Hyperscript. I'm suggesting we use Hyperscript to build the schema faster and read it easier. It would be an add-on on top of UIDL JSON, opt in, for those who want to write UIDL faster.

[JayaKrishnaNamburu]

Totally agreed 😄 👍

@JayaKrishnaNamburu I understand your point of view and share the idea that writing tags should not be the only way of writing things, however it's much easier for me to "build" the UIDL JSON by writing tags like the ones mentioned before. I also believe that defaulting some keys in the UIDL is not enough to make the project/document readable.

So no no, I don't suggest we move the UIDL schema from JSON Schema Definition to Hyperscript. I'm suggesting we use Hyperscript to build the schema faster and read it easier. It would be an add-on on top of UIDL JSON, opt in, for those who want to write UIDL faster.