Giter Site home page Giter Site logo

db-ui / mono Goto Github PK

View Code? Open in Web Editor NEW
40.0 9.0 6.0 601.17 MB

DB UX Design System Monorepo - Provides Design Tokens and components for Web UIs

Home Page: https://db-ui.github.io/mono/review/main/

License: Apache License 2.0

JavaScript 11.00% SCSS 29.07% EJS 1.96% TypeScript 38.10% HTML 14.60% Vue 4.78% CSS 0.34% Dockerfile 0.03% MDX 0.11%
design-system a11y accessibility angular components css html mitosis nextjs react

mono's People

Contributors

annsch avatar bruno-sch avatar d-koppenhagen avatar dependabot[bot] avatar dkolba avatar github-actions[bot] avatar kyubisation avatar leape avatar mfranzke avatar nmerget avatar snahn2209 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

mono's Issues

Provide current and LTS showcases for React and Angular

Especially to migrate from Angular 13, but to provide version Angular 14 and 15 showcases we'll introduce current and lts showcase folders at least for Angular and React, as both Svelte and Vue don't seem have a lower major LTS version (any more) at the moment.

Integrate postCSS Plugin CSSNANO

          We should definitely integrate something like that ([CSSNANO](https://cssnano.co/) looks promising, I've tested it the other day, it could even merge some declarations that we're currently spreading across some files for better separation), but this should most likely only squeeze out the last bytes – if we do have a general problem within our imports of our modular SCSS files, our users who might do an individual SCSS consumption and build would either still have this problem or additionally even also setup postcss on their end which might be acceptable, but still strange if we could instead analyze and fix our file imports instead.

Originally posted by @mfranzke in #228 (comment)

Theming / extension possibility

We most likely would need to differentiate in between regular and enterprise themes from the very beginning (like e.g. for a different general tonality). We do have this within e.g. DB UI Core and Base at the moment and need to even also enable it within this repo.

Do we need to have further issue templates?

Eval: "Breakpoints" in px or rem

    This is somehow more of a conceptual question, because the main difference is regarding whether those should change in case that only the text-size gets increased by browser settings vs. the zoom functionality is actually being used (e.g. in Firefox: "Zoom text only").

Originally posted by @mfranzke in #20 (comment)

Optimize CSS output out of SCSS build

Our CSS file has doubled in size, so it seems like we're having a problem with code redundancy (which you could even also see in WebDeveloper tools).

decide to use either npm i or npm ci during CI/CD

Within other installations we were using npm ci, and now only npm i within our CI/CD scripts. Let's find out what's best and document it. Most likely we would need npm ci for comparable builds (as only the lock file guarantees consistent versions).

Ignore major dependency updates for JS frameworks

Specifically for the JS frameworks (Angular, Vue, React) that we're providing showcases for, it's always about the current and the LTS version; in these cases we don't want to be flooded by PRs that include major version updates, that would also increase the major version for the LTS folders.

The easiest might be to deactivate major version updates specifically for these frameworks dependencies in total, as we would be aware and need to a lot of more work than just a PR to provide a new version, both in our output targets, as well as the showcase folders.

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore

This would be a followup to the existing entries: https://github.com/db-ui/mono/blob/main/.github/dependabot.yml#L21

test reactiveForms with DBInput

Currently we only tested template driven forms in angular.
Further tests should include the following:

  • [] validation in template driven forms
  • [] reactive forms with formGroups and formControls (defaultValue, validation, two.way-binding)
  • [] reactive forms validation

Click logging: understandable text

          let's rename this to something more clearly like you did with https://github.com/db-ui/mono/pull/250/files#diff-ad7e7a997beb8ef9a515ddb702af1aeb855c01a6f33dd6b43f6a1b045f1663c1R21 (or it's a leftover in https://github.com/db-ui/mono/pull/250/files#diff-1a9b5ad81b8ee2e24995352d594f2bb9a5ee1aee41ece3221071f00b5fd3d8d7R11)

Originally posted by @mfranzke in #250 (comment)

Textarea

As a followup for db-ui/core#223 we even also need to ensure that we collect general styles to the source/_patterns/01-elements/_form-elements.scss again.

Reevaluate using renovate instead of dependabot

As dependabot doesn‘t proceed with their grouping PRs feature at the moment, we should consider to use renovate (at least for the moment). there‘s some progress now regarding grouped updates: dependabot/dependabot-core#1190 (comment)

Besides that, it seems to have some further interesting defaults, that dependabot doesn't provide at all:

Instead of previous evaluations, it seems that renovate additionally provides a good stack of default settings.

ADRs for architectural decisions

We'll introduce partly a whole new techstack to this monorepo. We therefore need to document our decisions e.g. via ADRs.

e.g. dependabot:

  • provided by GitHub directly
  • easier to maintain and with meaningful defaults than e.g. renovate

followUp input component: do we need a min-width?

  • esp. for expressive input fields we should discuss a min width or max text length for label to prevent text-overflow
  • awaiting decision from design guidelines
  • tbd. e.g. display tooltips for long labels?

Test viability of testing CI locally with ACT

Check whether we can use ACT to run GitHub Actions locally.

Ideally we would be able to run all CI/CD steps locally, so one does not need to push into a remote branch to know whether the CI status would still be green.

fix: icons for input field

  • icons for data-variants should contain filled icons
  • invalid input does not include the error icon when input field is aria-invalid

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.