@elmsln @haxcamp @btopro #HAXTheWeb #drupal #webcomponents #edtech ✻ Full stack unicorn
Adjunct professor teaching about webdev, ethics, and everything in between
I agree w/ your concerns, they are valid and ones I share. Less so in the "simple" name space as our team makes lots of "simple" elements as a joke. It's built on top of LitElement so really if it had a scope (again, this is mostly PoC and I'm not entirely sure I want to go this way) I'd say the scope is:
A user knows what Javascript is but can't write it well
A user can write basic css and HTML
A user can conceptualize what a new element could be
I could see this as a way of getting a lot of the bits out of the way. Most likely I'd see it used with just CSS,HTML and the data properties area. Working at a teaching university we're always looking for a mesh of productivity and teaching tools; these "simple" elements could provide a way for junior developers to begin implementing design comps and converting old jQuery / component mock ups to legitimate, data binding aware web components.
With a json based approach we could easily build a HAX based UI that abstracts this and allows these type of users to create new web components by filling out a form.
Maintenance is really my concerns with the approach long term as I've just come off of refactoring our ~400 element portfolio from polymer.html to Polymer to PolymerElement to LitElement and am getting a bit port'ed out :).
Another branching thought from this is taking the json blob and using SimpleWC to make a real time updating UI via HAX, but then having a "download web component" button that actually translates it into the real deal. Almost stencil-esk but ripping it to LitElement instead of VanillaJS.
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 agree w/ your concerns, they are valid and ones I share. Less so in the "simple" name space as our team makes lots of "simple" elements as a joke. It's built on top of LitElement so really if it had a scope (again, this is mostly PoC and I'm not entirely sure I want to go this way) I'd say the scope is:
I could see this as a way of getting a lot of the bits out of the way. Most likely I'd see it used with just CSS,HTML and the data properties area. Working at a teaching university we're always looking for a mesh of productivity and teaching tools; these "simple" elements could provide a way for junior developers to begin implementing design comps and converting old jQuery / component mock ups to legitimate, data binding aware web components.
With a json based approach we could easily build a HAX based UI that abstracts this and allows these type of users to create new web components by filling out a form.
Maintenance is really my concerns with the approach long term as I've just come off of refactoring our ~400 element portfolio from
polymer.htmltoPolymertoPolymerElementtoLitElementand am getting a bit port'ed out :).Another branching thought from this is taking the json blob and using SimpleWC to make a real time updating UI via HAX, but then having a "download web component" button that actually translates it into the real deal. Almost stencil-esk but ripping it to LitElement instead of VanillaJS.
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 :)