IMO, there are two things stopping any kind of component from being able to be easily used with Playroom.
importing the component code into the Playroom build
Getting hints registered in the proper format
This PR provides an example for TS/ES web components (Lit) to be imported through the standard components.js but bypassing the normal export option by just exporting {}
Also, I added a new config option in playroom.config.js componentHints that takes either a function or a hints object. The results of that config property are passed to the CodeEditor component (manual hints are preferred if they exist) so that hints can be manually generated and passed into playroom in a case where the component authoring mechanism doesnt allow attribute types, props, defaults to be automatically deciphered.
This is my first contribution to an OSS project, especially one of this size, so please tell me where I've gone wrong or if you'd like to see a different approach. I wasn't sure that running cypress tests was relevant since i've only added a config prop, but I'm open to adding features to test the new config if need be.
This PR is something similar to work that my coworker has done locally to an install of playroom we have running. We use Lit web components, and having this config prop be native would simplify our playroom considerably, and let us just parse output from analyzer tools such as runem's web-component-analyzer or the new one open-wc is working on
IMO, there are two things stopping any kind of component from being able to be easily used with Playroom.
This PR provides an example for TS/ES web components (Lit) to be imported through the standard
components.js
but bypassing the normal export option by just exporting{}
Also, I added a new config option in playroom.config.js
componentHints
that takes either a function or a hints object. The results of that config property are passed to the CodeEditor component (manual hints are preferred if they exist) so that hints can be manually generated and passed into playroom in a case where the component authoring mechanism doesnt allow attribute types, props, defaults to be automatically deciphered.This is my first contribution to an OSS project, especially one of this size, so please tell me where I've gone wrong or if you'd like to see a different approach. I wasn't sure that running cypress tests was relevant since i've only added a config prop, but I'm open to adding features to test the new config if need be.
This PR is something similar to work that my coworker has done locally to an install of playroom we have running. We use Lit web components, and having this config prop be native would simplify our playroom considerably, and let us just parse output from analyzer tools such as runem's web-component-analyzer or the new one open-wc is working on
addresses #156