Skip to content
This repository was archived by the owner on Apr 13, 2025. It is now read-only.

Component: add AbstractComponent to separate Schema-constructable and raw component#251

Open
DavidPeicho wants to merge 1 commit intoecsyjs:devfrom
DavidPeicho:feature/abstract-component
Open

Component: add AbstractComponent to separate Schema-constructable and raw component#251
DavidPeicho wants to merge 1 commit intoecsyjs:devfrom
DavidPeicho:feature/abstract-component

Conversation

@DavidPeicho
Copy link
Copy Markdown
Contributor

Hi,

I quickly worked on adding a way to simplify schema-constructable component, as well as their typings.

Why?

Before, constructing a component using its schema was made at runtime, see here.

Separating the schema-constructable component versus raw component directly on the class makes the component a bit more cleaner I believe. From a TypeScript point of view, it also simplifies things as we can now pass a custom Properties object for AbstractComponent (see here), while still being able to keep the previous schema properties type on "normal" component (see here).

This PR solves mostly TypeScript issues rather than logic issues. It's really hard to construct component and keep types as safe as possible with the current design.

Improvements

It's highly possible that this design has some issues. If you think it's a good idea to start with we can go this route, and improve it with the community feedback.

@robertlong
Copy link
Copy Markdown
Member

robertlong commented Sep 10, 2020

Our intent for now is to keep schemas in the core Component class. You can create components without using the schema by calling super(false) in the component constructor and overriding any methods you want.

I agree the property and schema types can be repetitive when using typescript, but as soon as you factor in everything else that the schemas do for you at runtime, the amount of boilerplate is negligible.

We also don't really want to introduce another class into the component prototype chain. That will just make things slower. If your issue with the current design is type safety then we should discuss solutions around that. I think there is a decent way to write type-safe components right now with a little bit of boilerplate. See this example. If you have ideas for improvements to this pattern, we'd love to hear them! It is a little repetitive.

@DavidPeicho
Copy link
Copy Markdown
Contributor Author

I still feel that fundamentally, a TagComponent is different than a normal component... We can clearly separate this PR into two, first work only on the typings and think about that later.
To be fair, I was in holidays and I can't remember why exactly but the schema was a bit of a pain 😄

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants