scale icon indicating copy to clipboard operation
scale copied to clipboard

React implementation of Scale components

Open Theoderich opened this issue 3 years ago • 14 comments

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 [email protected] if you are interested.

Theoderich avatar Feb 22 '22 11:02 Theoderich

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.

christopherGdynia avatar Feb 22 '22 11:02 christopherGdynia

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 avatar Feb 22 '22 13:02 acstll

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

acstll avatar Feb 22 '22 13:02 acstll

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.

filipjnc avatar Mar 03 '22 20:03 filipjnc

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)

acstll avatar Mar 15 '22 16:03 acstll

@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

christopherGdynia avatar Mar 16 '22 06:03 christopherGdynia

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.

tkoelpin avatar Jun 07 '22 10:06 tkoelpin

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

christopherGdynia avatar Jun 07 '22 11:06 christopherGdynia

I just changed the title of the issue to "React implementation of Scale components" to avoid any confusion with "React Native". See https://github.com/telekom/scale/issues/890#issuecomment-1068197720 — 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.

acstll avatar Jun 08 '22 11:06 acstll

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?

christopherGdynia avatar Aug 11 '22 09:08 christopherGdynia

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! 🙏

acstll avatar Aug 22 '22 16:08 acstll

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 avatar Aug 30 '22 13:08 christopherGdynia

Hello @acstll,

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

christopherGdynia avatar Sep 29 '22 05:09 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"
    }
  }

christopherGdynia avatar Sep 29 '22 09:09 christopherGdynia