react-ui-org/react-ui

React UI is a themeable and performant UI library for React apps.

react-ui's Issues

Block merge of fixup commits

We don't want them in the main branch.

Consider passing custom attributes to components

Currently, most components cannot have custom attributes like className, aria-label or similar. It might be useful if they could — for example, adding CSS utility classes for offsets would be easier. Optional attributes could be of any type, they would not be defined in component's props.

Passing CSS class

Current state:

<div className="mb-3">
  <Button label="Button with classname" />
</div>

Proposal:
⚠️ This is not a desired solution, it could encourage people to hack the component's inner styles.

<Button className="mb-3" label="Button with classname" />

👉 Proposal: special utility props, see #18.

Passing eg. ARIA attribute for accessibility

Proposal (currently supported only in ButtonGroup and CardList):

<ButtonGoup aria-label="group">
  …
</ButtonGroup>

Create AutoScroll component

This issue is blocked by issue #53 (#58)

We need to create AutoScroll component that will be able to automatically scroll in selected direction when its content its updated. This functionality will be applied only if user will be scrolled at the edge of viewport. Component should detect change of content, it must not be detected by x or y coordinate because it will not work in case we will remove and add data at the same time.

We can create new AutoScroll component or implement it into ScrollView.

Lint commit messages

Check that commit messages are in the following format:

<Commit message text> (#<GitHub issue number>)

Create ScrollView component with automatic scrolling shadows

The component should:

• support horizontal or vertical scroll
• optionally hide scrollbar
• optionally show scrolling shadows where necessary

Image source: https://stackoverflow.com/questions/50654217/adding-horizontal-scrolling-shadows-effect/50655240

Sorting icons disappeared from Table

Sorting icons disappeared after recent refactoring of icons. They should be probably passed with props.

Better distinct disabled options in Select Fields and Multiple Select Fields

Mac is fine, we need to improve UX on Windows.

Components that wrap native elements should forward refs

Components that wraps native elements should forward refs, see https://reactjs.org/docs/forwarding-refs.html.

Following component should use this principe:

• Button
• Checkbox
• MultipleSelectField
• SelectField
• TextArea
• TextField
• Toogle

The only component that cannot use this princip is Radio, because it is rendered as list of radio inputs, so ref forwarding cannot be easily accomplished.

Generate development and production version of lib.js

Now we generate only production lib.js. We also need to generate development version of lib.js (probably lib.development.js) to be able to develop other applications with friendly named variables.

Disabled Card needs decreased text opacity

Card Body should have decreased opacity (configurable) in disabled state, similar to Buttons:

Currently it may not be clear that the Card is disabled.

Improve breakpoint scale

Largest breakpoints are currently too close: 84 em and 90 em.

Breakpoint values would be better off with a graded scale like this:

This will provide better control on largest screens.

Refactor Modal scrolling shadows to CSS

I can be done better: https://codepen.io/evank/pen/wWbRNO

Improve Table sorting buttons

Currently, the Button component is used for sorting arrows. It would be nice to have them aligned with text in the table, in the same color and without the button-style hover effect.

Maybe also reveal them on hover like in MUI?

(Created from #19, relates to #13).

Layout API for all UI components

As of now, adding an outer spacing to a component is done with utility classes like this:

<div className="mb-3">
  <Component />
</div>

This makes source code and DOM needlessly complex. It would be nice if we could do something like this:

<Component mb={3} />

This kind of “layout API” would be present in all UI components.

---

ℹ️ We don't want to make it possible to modify inner component styles so only outer CSS properties would be part in such API: margin (all directions), maybe flex child properties (align-self, justify-self).

Consider removing `Row` in favour of `Toolbar`

Toolbar's options justify="space-between" with nowrap have the same effect.

Fix loading icon of modal actions

Attribute loading of Modal prop actions needs to be changed to loadingIcon to be in sync with previous changes of Button props.

Fix `transferProps` function not to transfer `staticContext` prop

transferProps transfers staticContext prop of components that uses ForwardRef. This effect is not wanted and must be fixed.

Remove automatic spacing from form fields

Related to #41.

Providing form fields with no automatic margins should lead to a better expected behaviour. By far, automatic margins don't work as good as Toolbar or FormLayout.

Resets of auto margins have to be removed from the afore-mentioned layout components.

Unify `error` vs. `helperText` props

In all form fields (CheckboxField, MultipleSelectField, RadioField, SelectField, TextArea, TextField, Toggle):

• rename helperText to helpText
• use validationText for invalid/valid/warning validation message (ie. don't share the purpose with helperText)
• get rid of the error prop
• validate both *Text props as string or node to enable passing custom HTML such as links or icons

The new validationText would be styled according to the validationState prop.

---

As discussed in #20:

Mainly, we have to unify differences between usage of error vs helperText+validationState across all components, not only Radio, CheckBox and Toogle. It is weird to have different approaches of passing these values into components. So this is the first part of issue we probably agree on.

Then I am in to have two different props for setting these values, errorText and helpText, so we can set both independently. With this change, we will have to remove validationState prop and remove old error prop. And I also tend to use helpText instead of helperText.

The only thing I am not sure about is if we will need some help icon or not. If yes, then we will have to have prop for help icon, something like helpIcon. But it is only weak point I see now. Maybe icon is not necessary. It is totally up to @adamkudrna.

I am still thinking about icons because it is not so handy to pass all these icons like sortingAscIcon, sortingDescIcon, helpIcon (if it is needed) to components all the time. And in case we will need to have helpIcon then I would like to open discussion aboutIconContext component. We already have TranslationContext that can pass translations to components globally and it can be same for icons.

Originally posted by @bedrich-schindler in #20 (comment)

have two different props for setting these values, errorText and helpText
I like these names

The only thing I am not sure about is if we will need some help icon or not.

Could we make helpText and errorText accept nodes and/or text and then we could pass in the icons inline? That would open other possibilities such as passing into helperText a button that opens documentation modal and such things.

Something like (I didnt test this code):

<MyComponent
  helpText={<><Icon type="help"> I'm the help text.</>}
/>

Originally posted by @mbohal in #20 (comment)

Perform primary action and close `Modal` on enter

Modals should perform primary action and close on enter, just like they close on escape.

Toolbar layout enhancements

• enable vertical alignment for all items
• enable grouping of items
• ⚠️ BC: introduce justification options and remove ToolbarSpacer

Refactor Radio, Checkbox and Toggle

• Unify API with other form fields: error → helperText moved to #28
• Get rid of deprecated SCSS settings and tools (colors, forms, icons)

Modal sizes

It would be handy to have multiple sizes of Modal to choose from: small, medium (default) and large. Sizes should be configurable.

Create `Popover` component

Something like:

Document releasing and automate where possible

Steps

1. bump version in package.json according to SemVer, merge into develop via PR
2. merge develop into master via PR
3. draft GitHub release
   • use the same version as in package.json in step 1
   • set target branch to master (we want to keep develop the default branch for PRs)
   • summarise the changes, preferably divided into sections
4. npm publish — can be automated with official GH actions
5. build and deploy the docs to GitHub Pages, must include the latest version number (relates to #67)
6. close corresponding milestone — can be automated using third-party GH actions

A CONTRIBUTING.md file describing this workflow should be created (maybe in the .github folder?).

Extensions

Optionally:

• automatically close issues and milestone related to release using third-party GH app

Resources

• Example GitHub npm-publish workflow
• GitHub help on this ↑
• GitHub help on release event

Exclude documentation components from library

Documentation components are not needed for library consumers, they should provide necessary tools themselves when building the documentation on their side. Therefore the components should be moved to src/demo/components. They will be removed entirely once the demo is migrated to a new documentation platform (#15). This will also help us decrease the size of lib.js.

Consider secondary Button variant as deafult

Most buttons in app UIs are secondary actions. Primary variant is only used for primary actions which should be used far more sparingly (if not only once per screen).

Better form layout

We need the option to align form fields to the input field from the left side, even when they have auto-sized labels in horizontal layout. It must also work with vertical field layout (applied also for horizontal layout on small screens).

Add utility classes for text color (non-responsive)

We need a way to color text with UI colors: success, error, … etc., and some gray shades – eg. disabled or muted. These classes don't need to be responsive.

Apply ScrollView in Modal and responsive Table

Blocked by #53.

See https://codepen.io/evank/pen/wWbRNO. Blocked by #49.

Layout for centered CTA and secondary actions

We need a very specific layout for a centered CTA button and optional secondary actions on sides. This is required specifically for Load more button but it may be useful in other situations.

Decrease bundle build size

Webpack and npm report warnings:

• production/development mode has not been set
• recommended size limit 244 kB has been exceeded (1.12 MB)
• refactor deprecated npm's prepublish task

Create MenuButton components

Create MenuButton components according to following design:

Add `type` attribute to `actions` prop of Modal component

New documentation

Current documentation is very basic. It consists of:

1. Foundation showcase (colors, typography, icons, spacing, breakpoints)
2. Layout components showcase
3. UI components showcase
4. Screens showcase
5. Utility classes showcase

Problems:

• Developers find the docs hard to use because it doesn't contain important information like code examples or description of components' API.
• It is very difficult to maintain since it's held in a single file.
• Designers (and actually no one except contributors) cannot browse the docs because it's not served anywhere in public.

Proposal:

• Find a way to split the docs into multiple files and screens to improve maintainability and navigation in browser.
• Provide components with code examples to help developers use the components.
• Provide components with API description to help developers use the components. This could be generated from propTypes comments.
• Consider using external tools like Storybook as it solves many of the problems.
• Serve the docs as a website to encourage designers use the UI library and to make it accessible to public.

Individual issues are expected to be raised as discussion continues within this issue.

Dismissible Alerts

It might be useful if Alerts could be:

1. dismissible:
   
2. collapsible:
   
   

Remove automatic spacing of `Button`s in favour of `Toolbar` layout

Currently, margin is added to the right side of field/button if there is more than one field in current context (div). While this may work fine for wide screens, it breaks on small screens where vertical margin is missing. These automatic margins may also get work unexpectedly complicated eg. when there is a (invisible, absolutely positioned) modal or dropdown next to a button.

Since our existing Toolbar layout perfectly covers this problem (and does a lot more), we could get rid of this functionality.

Automatic margins don't work in vertical layout:

Toolbar layout:

Deploy documentation to public URL

Currently the docs isn't accessible anywhere. Everyone should be able to view it when needed.

Serve the docs as a website to encourage designers use the UI library and to make it accessible to public.

(Taken from #15)

We want to stick to GitHub Pages unless something really serious makes us not to.

The question is, where shall we store the built website and how do we get it there?

Prerequisites

1. GH Pages require a ready-to-deploy, static HTML website when not using Jekyll.
2. We must choose from three possible places to store the generated website.

Options

Storing the website

There are two relevant types of GH Pages:

• project
• organisation
• (user — not relevant for our use case)

We can store the generated site in:

• the original project repository
  • 👍in the same repository
  • 👎cluttering the main source code with generated code or involving awkward checkouts to the detached gh-pages branch, see below
• a separate repository dedicated to generated docs
  • 👍the original repository stays clean from generated code
  • 👎disconnected from the original repository

For project pages, the site is required to reside in either of these:

• gh-pages branch (project pages)
  • 👍not cluttering the main source code with generated code
  • 👎awkward to checkout locally
• master branch, docs directory (project pages)
  • 👍no explosive checkouts involved
  • 👎cluttering the main source code with generated code

For organisation pages or docs-dedicated project pages the site can live in the master branch.

Domain

• github.io:
  • project (the generated site is in the same repository in gh-pages or master branches): https://react-ui-org.github.io/react-ui
  • separate project (the site is generated to a different repository): https://react-ui-org.github.io/react-ui-docs
  • organisation (the generated site is in a separate repository): https://react-ui-org.github.io
• custom domain — sexy, but requires someone to pay the domain

Deployment

• let maintainers do it manually via push to one of destinations above — no guarantee that the docs matches the latest release
• automate the process using third-party GitHub apps/actions or a custom shell script like this one (relates to #71)

Configure CI

To test pull requests (and merges).

Support automatic Modal size according to its content

Looks like it could work — just add auto option to size with width: auto.

Add support for "minlength" and "maxlenght" attributes to <TextField>

They can be handy…

Improve inner IDs of inner component

Due to Selenium testing, IDs among UI components need to be updated to be more Selenium-friendly.

ID of UI component is passed to native element without change (for input, textarea, ...). ID with prefix __label need to be added to <label> tag, because ID with this prefix is now typically at last leaf, which is typically <span> that coitains label text.

Make transferred props more DRY

Related to #86.

It would be handy to combine the definition of props to transfer with propTypes. Currently it's white-listed aside like here in Button:

  const propsToTransfer = transferProps(
    props,
    ['afterLabel', 'beforeLabel', 'block', 'clickHandler', 'disabled', 'endCorner', 'grouped', 'id',
      'label', 'labelVisibility', 'loadingIcon', 'priority', 'size', 'startCorner', 'type', 'variant'],
  );

Code could be also more DRY and easier to write and maintain then.

Fix horizontal form fields too wide with custom input size

Form field shouldn't take more space than its help/error text width.

Enable generating documentation of advanced `propTypes` syntax

Added by @adamkudrna: This includes these useful ways of abstraction:

• propTypes assigned as value of a constant in the same file
• propTypes defined in another file

---

Based on issue: doczjs/docz#1431

We need to create documentation component that will allow us to render documentation table with all props and its description. This component should be similar to default docz PropType component, but need to be able to renders props that are composed from another proptype definitions.

I would recommend to move this component to separate repository later, because it seems that there are more people with same problem like we have.

Use `start` and `end` instead of `left` and `right` to be RTL ready

This includes:

• List variants alignRight → alignEnd and alignLeft → alignStart
• (utilities: text-left → text-start, text-right → text-end)

Dense Cards

It would be handy to have more compact Cards.

Remove unnecessary builds from repository

As we publish library on NPM registry, we do not need to have builds of library and demo in repository. We can gitignore them and publish only lib.js on NPM registry.

Make the project compliant with GitHub Community profile

See https://github.com/react-ui-org/react-ui/community:

Help on GitHub: https://help.github.com/en/github/building-a-strong-community/about-community-profiles-for-public-repositories

Update dependencies