neb42 / ui-studio Goto Github PK

Current docs is a first pass. There are probably a lot of overlooked or poorly described concepts. My english language skills are also pretty poor so it doesn't read well.

This started as a small personal project so there were no tests. It really needs some tests as I'm relying on typescript compilation and manually testing to check that things work.

When using a widget property as a widget value it is restricted to widgets in the same page. With variables, a variable can use a widget value from any page and any variable can be used on any page. This allows for sharing widgets across pages.

We're currently using OpenAPI 3.0.

3.1 adds in arrays of types. This is useful as a component config item may want to accept multiple types, eg. the Text component could accept anything and convert it to a string. We should also aim to stay up-to-date with OpenAPI.

This needs some thinking as to how we will handle it both coming from the API, in the component definitions, and in the builder client.

• If an API returns ['string', 'number'] and the component expects 'string' is that valid?
• If an API returns 'string' and the component expects ['string', 'number'] is that valid?
• If a component config item has multiple types in a static mode, what do we render? Is there a priority list? array/object, string, number, boolean?
• If a component config item has multiple types including array or object should we still support form mode?

Need to figure out how to detect when client is ready and either open the UI then or change state of UI based on that

When changing the style type of a widget it's children will have their styles reset to match the parent layout. This is correct, but if there are any common styles (eg. css, class names, background colour) they should be preserved.

When the tabs change the index is kept rather than the key. When switching across widgets it should stay on the same tab key or default to index 0 if it does not exist.

Killing the parent process leaves the port in use

A modal is an element that blocks interaction with the rest of the application. This can be a dialog, a drawer, a menu, etc.

My current thinking is that they should be treated like pages, introducing a new element type:
type: 'page' | 'widget' | 'customComponentInstance | 'modal';

A new event type is added open-modal and close-modal or toggle-modal. This will similarly to navigate-page.

When a modal is opened the page will not change and the modal will be rendered over it.

Components will receive a new closeModal prop that will close the parent modal.

Should we support nested modals?

Currently the render engine uses CRA. It'd be great to make this modular so we can render the same JSON tree in different ways. The current use case would be to make a Next JS render engine.

• Start with yarn start
• Wait for everything to spin up
• Kill with ctrl + c
• Preview client process is still running

When using an exposed widget property as a value we should be able to cast the property to the required type for the value if applicable.

eg. number 1 => string "1", boolean True => string "True"

Things like an object or array cannot be cast.