React implementation of Scale components

[Theoderich]

Hello Scale Team,

my company is currently developing multiple React-Projects for Telekom.
We were very happy to discover the Scale Framework for easy access to Telekom styled components.
Unfortunately, using Scale with React proved to be very difficult. The interop between the auto generated wrapper components and React is clanky at best. React is in general ill suited to ingrate non-react components.

Optimally, we would have Scale components that use the original css from the scale-components, but with the Javascript part implemented natively in React. So I went ahead and did just that.

In the below repository, you can find all of the Scale components we currently use in our projects implemented with React.
You will also find our reasoning why we do not want to use the auto generated wrapper components in the README.md.

Since the Scale License explicitly states that those parts are not Open-Source, have we removed the /telekom components for the open source release and switched the theme to neutral. In our internal version, we actually use the Telekom-Theme and have also implemented the AppShell, AppHeader and AppFooter. We would be happy to share those too, but are unsure of the legality.

https://github.com/qaware/scale-react-neutral

Optimally, we would like to integrate this work into the official Scale repository. Although it adds the burden of maintaining multiple implementations of the same components, we think it is worth the effort. The implementations are quite similar and can easily be developed in parallel.

Feel free to contact me via Github or at andreas.janning@qaware.de if you are interested.

[christopherGdynia]

Hello @Theoderich,

We are using React aswell and there are some issues with the wrapper library (many are fixed with workarounds) and many problems with the native components.

I will support and contribute to it.

[acstll]

Hey @Theoderich, thanks a lot for sharing. This is quite impressive and interesting.

Regarding the approach ("official" CSS with React logic), it's completely legit, but we're not 100% sure we would want this, for the reasons you've already mentioned.

There has been some recent efforts in React to make custom elements work better (currently in the experimental dist). And we were also thinking lately about how a new less-automatic wrapper library would look like (one little step back compared to your approach). So we have hopes still…

But nevertheless we're definitely open to considering it!

Please give us some time to evaluate it and get back to you.

Thank you very much 🙏

[acstll]

Regarding the legal part, we can also try and clarify this, but I think you did the right thing 👍

[filipjnc]

I'm with @Theoderich on that. The react ecosystem is vast and its usage is vast, also in Telekom. Teams use react-native to build cross-platform apps, next.js for SSR, and more.

The interop between wrapper components and React is already degrading DX, throw in react-router or SSR and it's errors after errors and a lot of unexpected behaviors. I will try to document most aggravating issues in this repository, yet I have the feeling only a React-implementation of these components can offer decent DX and lean code without workarounds.

[acstll]

Thanks for the feedback @filipjnc

For clarification —because I think the "Native" in the issue title might be misleading—, the React-only library @Theoderich is working on is for react-dom (renders HTML). As far as I know —correct me if I'm wrong—, you wouldn't be able to use those components in a React Native app directly. I believe you can wrap them but I'm not exactly sure how that works. So for React Native we would need yet a separate component library, correct?

I will try to document most aggravating issues in this repository
please do, this would be very valuable feedback. You can get in touch directly if you think it makes sense (ac at iconstorm.com)

[christopherGdynia]

@acstll, you are right about it.

React Native uses web views, and ReactJS html components.
Although, you can use ReactJS components inside of a web view.
The components needs to fill the space inside the webview, according to stackoverflow answer

[tkoelpin]

I really wanted this Feature too, we're building an App for the Deutsche Telekom and we need this Feature as soon as possible. I tried my best for the textfield, but it still didn't go well.

[christopherGdynia]

How about we open a branch and start adding the components and see what everyone has worked on so far?!

[acstll]

I just changed the title of the issue to "React implementation of Scale components" to avoid any confusion with "React Native". See #890 (comment) — I hope that's fine…

What feature do you mean exactly @tkoelpin?

As a status update, we haven't been able to reach any agreement internally regarding this topic, yet (whether we should officially support a React-only version of the library). But this is still pretty much open 🔥 — thanks for the patience.

[christopherGdynia]

Hello @acstll

I have implemented some components like button or have build many proxys for input components.
We are creating more and more components, which are a react implementation of scale.

We have multiple problems, which lower dx and ux.

I strongly support a react package and as I said, I will develop components for this package.

@Theoderich any updates on your site?

[acstll]

Hey @christopherGdynia — thanks for the patience once more.

To be completely honest, I'm rather hesitant to the idea of a React-only implementation of Scale. For 3 reasons, in order of importance:

Accessibility. One of the key features of Scale is caring for accessibility. All the efforts could get lost with a completely new implementation. There is no way we can guarantee this React-only implementation is also as accessible if we don't test it exclusively.

It's not our fault, but theirs. React is the only one of the famous —and not so famous— frameworks currently not fully supporting Web Components (Preact, Svelte, Angular, Vue, Solid… and so on, do support them out of the box — TypeScript support is something else). And it's just a matter of will (aka wanting to…). It's like they just don't care. And we're talking about a standard browser API, not some arbitrary/proprietary thing.

The limitations are only 2. Although they can be painful, it's only "data binding" and "custom events"; as explained here at Custom Elements Everywhere and our own docs.

What I would do

I would be in favor of creating a new wrapper package that is just better than the flaky current one. I believe this is possible based on the examples below:

Atomico — completely custom wrapper
https://atomico.gitbook.io/doc/guides/atomico-and-react
https://github.com/atomicojs/react/blob/master/src/core/create-wrapper.ts

Shoelace — they leverage @lit-labs/react in a custom wrapper also
https://github.com/shoelace-style/shoelace/blob/next/scripts/make-react.js
https://github.com/lit/lit/tree/main/packages/labs/react

Next steps

The very first thing, thou, would be to make an extensive and descriptive list of all the UX and DX issues you've encountered, so we can make sure we're actually solving them with the new wrapper.

Is this something you could do @christopherGdynia? It could be a collective effort too. You start dumping ideas and then refine into a final list…

(Afterwards, we could also create a suite of automated tests to support this list before we develop the wrapper.)

Please let us know what you think! 🙏

[christopherGdynia]

Hello @acstll

the most annoying part about webcomponents is, that they loose style and render not properly.

This is really random and annoying, I will post it below, when it happens again and I remember to screenshot it.

[christopherGdynia]

Hello @acstll,

I can't upload images to github, how can I share it?

[christopherGdynia]

I have made a small step forward, as I said the styles are missing.
These styles get injected in style tags into the html head, but not all of them get injected.

Do any of you guys have an explanation for this?

dependencies:

 {
    "dependencies": {
      "next": "12.2.5",
      "@microsoft/signalr": "3.1.17",
      "@telekom/scale-components": "3.0.0-beta.102",
      "@telekom/scale-components-react": "3.0.0-beta.102",
      "axios": "^0.27.2",
      "copy-to-clipboard": "^3.3.1",
      "date-fns": "^2.22.1",
      "formik": "^2.2.9",
      "react": "^17.0.2",
      "react-beautiful-dnd": "^13.1.0",
      "react-dom": "^17.0.2",
      "react-dropzone": "^14.2.2",
      "react-query": "^3.17.1",
      "react-table": "^7.7.0",
      "react-virtual": "^2.10.4",
      "sass": "^1.49.0",
      "styled-components": "^5.3.0",
      "yup": "^0.32.9"
    },
    "devDependencies": {
      "@types/node": "^12.20.18",
      "@types/react": "^17.0.15",
      "@types/react-beautiful-dnd": "^13.1.2",
      "@types/react-dom": "^17.0.9",
      "@types/styled-components": "^5.1.10",
      "@types/react-table": "^7.7.9",
      "next-transpile-modules": "^9.0.0",
      "autoprefixer": "^9.8.6",
      "postcss": "^8.4.4",
      "tailwindcss": "^3.0.0",
      "typescript": "^4.3.5",
      "@types/lodash": "^4.14.178"
    }
  }

[tshimber]

a long conversion here. @Theoderich @christopherGdynia please tell if the issue is still relevant. All the guys are now working on the new OneDS lib, which is meant for React. maybe those issues will be solved in there

[christopherGdynia]

@tshimber Can you please link the OneDS lib?

WebComponents have some problems when working with react

Last Problem we had was defaultValues for ScaleRadio

Or the changes of @types/react when stencil had a lower version and we are now using react@18 with @types/react@17

We still would appreciate a standalone react package