https://github.com/adbayb/poc-cross-framework-component
🧪 Cross-framework approaches to implement components in a framework agnostic way
https://github.com/adbayb/poc-cross-framework-component
proof-of-concept
Last synced: 3 months ago
JSON representation
🧪 Cross-framework approaches to implement components in a framework agnostic way
- Host: GitHub
- URL: https://github.com/adbayb/poc-cross-framework-component
- Owner: adbayb
- License: mit
- Created: 2022-04-10T10:29:25.000Z (about 3 years ago)
- Default Branch: main
- Last Pushed: 2023-12-15T17:25:42.000Z (over 1 year ago)
- Last Synced: 2025-01-05T05:42:03.296Z (5 months ago)
- Topics: proof-of-concept
- Language: TypeScript
- Homepage:
- Size: 418 KB
- Stars: 2
- Watchers: 2
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
🧪 Cross-framework component
Experiment several approaches to consume components in a framework agnostic way
## 🤔 Motivation
This repository aims to experiment several approaches to implement cross-framework components.
By cross-framework, we mean a component compatible with several frameworks.
## ✅ Requirements
Following minimum requirements have been identified:
- Consistent API across frameworks
- Shared core logic (accessibility, state, styling, ...)
- SSR friendly
- Encapsulation (style isolation)
- Developer experience
## 🧪 Experimentations
Three approaches have been tested:
- **[Wrapper](wrapper) (top-down runtime approach)**: packages existing framework dependent components with a thin interoperability layer to create framework agnostic components consumable by any frontend stack. This layer acts as [a decorator](https://refactoring.guru/design-patterns/decorator) to generate standard custom elements with added superpowers (eg. adding server side rendering support by letting the underlying framework manages it).
This approach can be interesting to explore if we need to deal with the existing (ie. already developped components) or if the team wants to use (for developer experience concerns...) a specific UI framework.
- **[Primitive](primitive) (bottom-up runtime approach)**: framework agnostic low-level building blocks. They allow to build high-level components without dealing with framework specificities. Each primitive acts as [an adapter](https://refactoring.guru/design-patterns/adapter) to plug framework dependent logic.
This approach can be interesting to explore if requirements must be supported in an optimal way consumer side (eg. no extra size footprint...).
- **[Compiler](compiler) (build time approach)**: Use a build tool to generate, from a single source code, either web component (eg. via [Stencil](https://stenciljs.com/)) or per framework implementations (eg. via [Mitosis](https://github.com/BuilderIO/mitosis)).
Others approaches have also been considered but are not suited to our defined requirements:
- Use web standards only (web component): while it's future-proof, it can come with several challenges (developer experience, server side support...). For example, SEO constraints: rendering web component is not natively possible server side since the standard relies on web client APIs. By natively, we mean without introducing extra tool such as DOM emulation or headless browser for prerendering purposes.
- Re-implement the whole library per framework: we would like to share as much as possible the core logic.
**TODO:**
- [ ] Add compiler implementation
- [ ] Add rendering benchmark (wrapper approach)
- [ ] Fix reactive props Vue side (primitive approach)