I've been dreaming of json powered UI's a lot recently. There's only so many ways you can rebuild the same base component before you figure out the data you need to start automating the boring stuff.
The real power comes when you combine json powered components with graphql and tailwindcss or something similar. You can declare any css you need using an array of tailwind classes, which can be passed around and composed however you want. Storing entire theme presets would be very doable.
If you're storing components as primarily JSON data then your gql schema would already map almost perfectly to your component structure, which I imagine would be a fun convention to prototype with.
And I don't think this locks you into a framework, I think it's your way out. If your data is stored in a portable schema you can transform it into whatever you need it to be and back again.
@elmsln @haxcamp @btopro #HAXTheWeb #drupal #webcomponents #edtech ✻ Full stack unicorn
Adjunct professor teaching about webdev, ethics, and everything in between
because the like doesn't do it justice. I agree 100% here, well put. While this post was just a prototype I've started seeing some other similar concepts and while I don't love the abstraction === magic route all the time, I love the notion of GQL or even traditional CMS monolithic backends being able to dynamically inject definitions for front end elements on the fly.
I agree you can only go so far with magic conventions, but you would really only be able to do this with dumb, themeable components anyway. Which I think is a good candidate for abstraction.
being able to dynamically inject definitions for front end elements on the fly
This, exactly. Dynamic module imports should help open the door to this but you need some kind of easily understandable central data contract to keep everything in line. Types & Classes just don't travel as well as a JSON schema.
@elmsln @haxcamp @btopro #HAXTheWeb #drupal #webcomponents #edtech ✻ Full stack unicorn
Adjunct professor teaching about webdev, ethics, and everything in between
don't travel as well as a JSON schema. --- We use JSON Schema as well as an abstraction of it we wrote called HAXSchema to power headless forms via a single tag -- npmjs.com/package/@lrnwebcomponent...
Can see it running here: haxtheweb.org/ when you edit anything and it builds the form on the left that says Layout, Configure, Advanced; that's from HAXSchema being read off of the element and set as schema / values on the simple-fields element :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've been dreaming of json powered UI's a lot recently. There's only so many ways you can rebuild the same base component before you figure out the data you need to start automating the boring stuff.
The real power comes when you combine json powered components with graphql and tailwindcss or something similar. You can declare any css you need using an array of tailwind classes, which can be passed around and composed however you want. Storing entire theme presets would be very doable.
If you're storing components as primarily JSON data then your gql schema would already map almost perfectly to your component structure, which I imagine would be a fun convention to prototype with.
And I don't think this locks you into a framework, I think it's your way out. If your data is stored in a portable schema you can transform it into whatever you need it to be and back again.
because the like doesn't do it justice. I agree 100% here, well put. While this post was just a prototype I've started seeing some other similar concepts and while I don't love the abstraction === magic route all the time, I love the notion of GQL or even traditional CMS monolithic backends being able to dynamically inject definitions for front end elements on the fly.
I agree you can only go so far with magic conventions, but you would really only be able to do this with dumb, themeable components anyway. Which I think is a good candidate for abstraction.
This, exactly. Dynamic module imports should help open the door to this but you need some kind of easily understandable central data contract to keep everything in line. Types & Classes just don't travel as well as a JSON schema.
Sanity.io has a fun example showing what you can do with structured content: github.com/sanity-io/sanity-templa...
don't travel as well as a JSON schema.--- We use JSON Schema as well as an abstraction of it we wrote called HAXSchema to power headless forms via a single tag -- npmjs.com/package/@lrnwebcomponent...Can see it running here: haxtheweb.org/ when you edit anything and it builds the form on the left that says Layout, Configure, Advanced; that's from HAXSchema being read off of the element and set as schema / values on the simple-fields element :)