You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- [Support for each implementation](#support-for-each-implementation)
148
149
-[Component libraries](#component-libraries)
149
150
- [Shoelace](#shoelace)
150
-
- [Material Design](#material-design)
151
151
- [Custom widgets](#custom-widgets)
152
152
-[Validation](#validation)
153
153
-[Schema massaging](#schema-massaging)
@@ -863,41 +863,102 @@ to deal with various template languages limitations (this is an universal proble
863
863
864
864
## Component libraries
865
865
866
+
> **Warning**
867
+
> Before you dive in, here is some context about Web Components libraries support with JSFE.
868
+
869
+
Whereas you are starting from scratch or you want to integrate declarative forms in
870
+
an existing project, you'll want to **choose** an UI library or **build** your own from scratch (or a mix of both).
871
+
In either case, JSFE got you covered up, as an agnostic platform for consuming
872
+
standardized form inputs widgets (see [types](./packages/types/src/widgets.ts)).
873
+
Web Components technologies has a lot of traction in 2022-23, with big names
874
+
launching their own collections. As any flourishing eco-system, there are _opinions_.
875
+
Fortunately, _most_ divergences happens on the _CSS side_. Specifically on styles consuming mechanisms.
876
+
877
+
As the initial maintainer, I decided to focus on _Shoelace_, while experimenting with other **great** options out there.
878
+
Why so?
879
+
880
+
- Keep an eye on converging practices across vendors.
881
+
- Ensure that _JSFE_ remains not to tied with _Shoelace_ way of things (which is already quite thin, relatively).
882
+
- Be able to swap out built-ins for custom widgets on a pinch, when needed.
883
+
- Borrow valuable ideas from others libraries and re-implement them in Shoelace when lacking.
884
+
885
+
> **Warning**
886
+
> I will not maintain the full spectrum of _JSFE_ widgets, accross all libraries!
887
+
888
+
But I will do my best to provide all the hooks you need, thanks to an _agnostic_ and _type-safe_ API,
889
+
smoothening some peculiarities.
890
+
891
+
Also, expect varying support for CSS implementations as for now, in 2023, it's just a bit too wild too keep up.
892
+
893
+
Non-exhaustive notes about what you might deal with WC components libraries' CSS:
894
+
895
+
- Carbon use pure SCSS import, with mixins. Only root element seems to be allowed for CSS vars injection (no `:host` or `<body>`…).
896
+
- Material UI uses a JS color utility to inject CSS vars on `style` attributes, with a sophisticated color generator.
897
+
- Shoelace is straightforward by giving us regular CSS files with vars I can apply on a boring class. But that also means you have to build your own color palette if you want to match your brand (it's easy).
898
+
- Spectrum use licensed fonts it seems?
899
+
- Spectrum has a tricky dependencies injection system, it took me the longest to achieve, and it's not perfect yet.
900
+
901
+
I'll not expand up furthermore on that, but if you're curious, it's you're lucky day. You can [see and compare all styles implementations across UI libs in examples](https://github.com/json-schema-form-element/examples/blob/main/src/themes).
902
+
Also, I recommend that you take a peek at the [playground source-code](https://github.com/json-schema-form-element/playground) for themes wizardry.
903
+
904
+
I find little gems in all of these frameworks, for example:
905
+
906
+
- Carbon has neat rocker switchs for numbers
907
+
- Adobe kills it with colours
908
+
- Wired is fun
909
+
- Material has an innovative color themes generator
910
+
- …you'll find some others too!
911
+
912
+
I'm not an expert on each of this libs., and please note many of them are quite new / rapidly evolving.
913
+
That's why it's interesting to keep a bird-eye view from time to time.
914
+
915
+
Overall, Shoelace seems to be the most equilibrated in my eyes.
916
+
If you require top-notch support for you favourite UI lib. which is not Shoelace,
917
+
I encourage you to contribute,
918
+
like people did for the [React JSON Schema Form](https://github.com/rjsf-team/react-jsonschema-form) project.
919
+
Core maintainers are working on the reference implementation, and community can add things of their interest.
920
+
921
+
If you want to enhance the lib. by supporting for more fields, it's quite easy!
922
+
Just take a peek on the [Shoelace package](./packages/shoelace),
923
+
which is the canonical implementation (meaning it's the most complete, API-wise).
924
+
Then, you are welcome to make a pull request with new features, or bug fixes.
925
+
866
926
### Shoelace
867
927
868
928
[Shoelace](https://shoelace.style/) is the UI component library of choice for rendering fields, and as a
869
929
general design system backbone for _JSFE_.
870
930
It's beautiful, aims for simplicity, is not too opinionated, while still having character.
871
931
That's why it's the very first library implemented in _JSFE_.
872
932
873
-
### Material Design
933
+
<!--### Material Design-->
874
934
875
-
🚧……🚧
935
+
<!--🚧……🚧-->
876
936
877
-
Support for [Google Material 3 Web Components](https://material-web.dev) is planned.
937
+
<!--Support for [Google Material 3 Web Components](https://material-web.dev) is planned.-->
878
938
879
939
### Custom widgets
880
940
881
941
🚧……🚧
882
942
883
-
It's totally doable to swap some or all components for another
884
-
system, thanks to the very Custom Element flexible nature.
943
+
<!-- OLD -->
944
+
<!-- It's totally doable to swap some or all components for another
945
+
system, thanks to the very Custom Element flexible nature.
885
946
First step would be to create a generic interface
886
-
for communicating with individual fields, starting with the raw system browser ones as a reference. That might add a fair amount of complexity and some (negligible?) performance impact though.
947
+
for communicating with individual fields, starting with the raw system browser ones as a reference. That might add a fair amount of complexity and some (negligible?) performance impact though.
887
948
Main benefit could be to add some “missing” components in Shoelace, like
888
949
combobox, complex date-time ranges, or whatever fancy widget your dreaming of.
889
950
890
951
For example, _React JSON Schema Form_ does support a handful of different UI libraries maintained by the community,
891
-
but AFAIK, in the Web Component space only Shoelace is on par, thanks its Lit backbone, all while beeing totally FLOSS.
952
+
but AFAIK, in the Web Component space only Shoelace is on par, thanks its Lit backbone, all while beeing totally FLOSS.
892
953
Things are changing fast though, thanks to a growing WC ecosystem, with big names backing it up (Adobe, MS, Google, IBM, SpaceX… basically everyone).
893
954
894
955
For now, the _JSFE_ component is one Lit Element monolith. All sub-parts are “partials“,
895
956
not individual Web Components. Those snippets are wrapping the Shoelace
896
957
components and make them aware and alive.
897
-
The validation logic / UI options are mostly happening there.
958
+
The validation logic / UI options are mostly happening there.
898
959
Choice has been made to tie the logic closely with the component.
899
-
While this practice should be avoided generally, here we have a fully declarative / programmatic UI, so no need to create more levels of indirection than needed.
900
-
Mapping between schema and “real” fields happens at the `HTMLElement` level, same as all validation stuff, though you got hooks / bypasses for custom behaviors (see below).
960
+
While this practice should be avoided generally, here we have a fully declarative / programmatic UI, so no need to create more levels of indirection than needed.
961
+
Mapping between schema and “real” fields happens at the `HTMLElement` level, same as all validation stuff, though you got hooks / bypasses for custom behaviors (see below).-->
0 commit comments