cozy / cozy-ui

React components and CSS styles for Cozy apps

Cozy UI

CSS classes and React components designed to build Cozy apps.

If you plan to build a webapp to run on Cozy, you'll probably want to use a simple and elegant solution to build your interfaces without the mess of dealing with complex markup and CSS. Then Cozy UI is here for you!

Cozy UI relies heavily on Material UI v4 and it can be useful to know how it works.

React components (styleguidist)

Check out UI components to see how to use ready made React components.

CSS Styleguide

Check the styleguide to see all the variables, mixins, classes, utilities and how to use them with only CSS classes.

Usage

As a Components library

Add Cozy UI to a dependency to your project.

yarn add cozy-ui

If you use the transpiled components (from cozy-ui/transpiled/react), you need to import the stylesheet (once):

import Button from 'cozy-ui/transpiled/react/deprecated/Button'
import 'cozy-ui/transpiled/react/stylesheet.css'

<Button />

You're now ready to use Cozy UI's React components

Utility classes

React components only come with the needed style, nothing more, but you may need some more utility classes to build your apps.

To do so you have at your disposal a special CSS build cozy-ui.utils.min.css that you can add like this:

import 'cozy-ui/dist/cozy-ui.utils.min.css'

As a vanilla CSS library (deprecated)

The entire library is also available as a good ol’ CSS library. You can simply add it to your app by linking the distributed minified file.

<link media="all" rel="stylesheet" href=“cozy-ui/dist/cozy-ui.min.css" />

Develop on Cozy UI

If you want to develop inside cozy-ui, you need a local version cozy-ui.

git clone [email protected]:cozy/cozy-ui.git

Install

First nvm use (to set node version as defined in .nvmrc) then yarn install

Develop inside the styleguidist

It is convenient when modifying a component to use the styleguide site.

yarn makeSpriteAndPalette # Create sprite and palette
yarn start # Transpile the files in watch mode
yarn build:css:all # Build CSS files needed by the documentation
yarn start:doc # Run the styleguide in watch mode

Add a component

If you want to add a new component, you must follow these steps:

• Add the new component in /react folder with its README.md file
• Expose it in the API by adding it in react/index.js
• Add it in the documentation by modifying docs/styleguide.config.js
• If necessary you can add snapshots for it by modifying react/examples.spec.jsx and updating them yarn makeSpriteAndPalette && yarn build && yarn test -u
• Remember to propagate the possible ref with React.forwardRef. See forwardRef documentation
• Try to think of ARIA attributes if you are coding new components

Be careful to respect MUI API when creating a new component. See our guidelines to create a new component.

Rename/Move a component

When renaming or moving a Cozy-UI component, it may cause a breaking change. In this case, you should provide a codemod as much as possible to fix it.

Guidelines for component development

• Use material UI whenever possible
• Override material UI components inside makeOverrides.js when necessary
• Avoid stylus to style new components based on MUI and prefer /helpers/makeStyles
• Use semantic variables for colors from stylus/settings/palettes.styl, or color from theme objects in makeStyles

Add an icon

If you want to add a new icon to cozy-ui, you must follow these steps:

• If you SVG file is an icon (not an illustration), verify that the file doesn't have any fill or fill-opacity properties. Remove them if necessary
• Add the SVG in the assets/icons/[ui || illus] folder
• Optimize it with yarn svgo assets/icons/[ui || illus]/[new icon file name]
• Generate the react component by running yarn makeSvgr assets/icons/[ui || illus]/[new icon file name]
• Update the documentation by adding the new file in react/Icon/Readme.md. If it's an icon, add it in SVGr icons and Available UI icons sections, or in SVGr illustrations and Available illustrations sections if it's an illustration
• Don't forget to check the icon's color on different theme (inverted, etc.)
• Update the tests by running yarn makeSpriteAndPalette && yarn build && yarn test -u

Develop inside an app

Sometimes, you want to develop on a component, from the context of an app. Then you need to link cozy-ui with yarn link. Since cozy-ui is transpiled, when linking you must first yarn release. If you change the icons, or the palette, you must run yarn release again.

cd cozy-ui
yarn makeSpriteAndPalette # if first time
yarn link
yarn start # Launch transpilation
yarn makeSpriteAndPalette # if you change icons or palette

Then in your application folder, you can link to your local Cozy UI. You can use rlink instead of yarn link. It will prevent common build problems due to module resolution inside symlinked folders. If your application doesn't use cozy-ui directly as dependency but through a library, you have to use rlink inside your application folder, not inside the library's one. rlink only copies the build and not the node_modules of cozy-ui, so you have to install a version of cozy-ui before making a rlink.

cd my-app
rlink cozy-ui # Prefer rlink to yarn link
yarn start

All your modifications in your local Cozy UI will now be visible in your application!

Making a demo when creating a pull request

When sending a PR, if your changes have graphic impacts, it is useful for the reviewers if you have deployed a version of the styleguidist containing your changes to your fork's repository. Don't forget to change USERNAME by yours.

yarn makeSpriteAndPalette
yarn build
yarn build:css:all
yarn build:doc
yarn deploy:doc --repo [email protected]:USERNAME/cozy-ui.git

⚠️ If the deploy:doc failed, you need to checkout your dev branch by doing git checkout -

Unit testing

Be aware that snapshots in unit tests use the transpiled version of cozy-ui. Therefore if you make changes and need to update the snapshots, you need to transpile first.

yarn makeSpriteAndPalette && yarn build && yarn test -u

We suggest to use @testing-library/react over enzyme for tests. We have historically used enzyme but we prefer the philosophy behind testing-library since it pushes to test for what the user sees.

For complex components, we expose testing helpers in the testing file in their respective folders.

import { getCloseButton, getAllDialogs } from 'cozy-ui/transpiled/react/CozyDialogs/testing'

it('should close dialog', () => {
  const onClose = jest.fn()
  const root = render(<MyApp onCloseDialog={onClose} />)
  const dialog = getDialog(root)
  const closeBtn = getCloseButton(dialog)
  fireEvent.click(closeBtn)
  expect(onClose).toHaveBeenCalled()
})

UI regression testing

Components in cozy-ui are showcased with React Styleguidist. To prevent UI regressions, for each PR, each component is screenshotted and compared to the master version to find any regression (thanks Argos !).

If your app uses React Styleguidist, cozy-ui provides rsg-screenshots, a CLI tool to take screenshots of your components (uses Puppeteer under the hood).

yarn add cozy-ui # The rsg-screenshots binary is now installed
yarn makeSpriteAndPalette
yarn build:doc:react # Build our styleguide, the output directory is docs/react
rsg-screenshots --screenshot-dir screenshots/ --styleguide-dir docs/react # Each component in the styleguide will be screenshotted and saved inside the screenshots/ directory

See our travis configuration for more information.

License

Cozy UI is developed by Cozy Cloud and distributed under the MIT license.

What is Cozy?

Cozy is a platform that brings all your web services in the same private space. With it, your web apps and your devices can share data easily, providing you with a new experience. You can install Cozy on your own hardware where no one profiles you.

Community

You can reach the Cozy Community by:

• Chatting with us on IRC #cozycloud on irc.freenode.net
• Posting on our Forum
• Posting issues on the Github repos
• Mentioning us on Twitter

cozy-ui's Issues

Modals in mobile mode

Par défaut les boutons sur la modale en mode mobile ne sont pas optimaux :

Je propose de les rendre comme ça :

Des remarques ? @Claiw @GoOz ?

hello ui

houston we have problemz

Spinner with color in CSS

Right now you need to have one spinner per color. On cozy-maif, I removed the fill attribute on the SVG file to be able to color the spinner with fill in CSS.

https://gitlab.cozycloud.cc/labs/cozy-maif/commit/826447c2e4f4e0670a93507a7aeb258a42d36105

What do you think of this approach ? I can make a PR.

Use an only one logic for react components exporting

I suggest:

• Export normally all components and also the main component as default

  import { MainComponent } from 'cozy-ui/react/Component' // should work
  import MainComponent from 'cozy-ui/react/Component' // should work
  import MainComponent, { other1, other2 } from 'cozy-ui/react/Component' // should work
  import other1 from 'cozy-ui/react/Component' // should NOT work

• Put clearly in the related documentation what is "importable" by the developper

Spinner acts weirdly

As shown on the Styleguide : https://ptbrowne.github.io/cozy-ui/react/#spinner

• It does not show its true color : #196 (comment)
• Sometimes size is not working (property width/height being shadowd by .coz-spinner) -
• noMargin seems to do nothing.

Lets dialogs be more flexibles

Dialogs are constraint to ()vh (

cozy-ui/src/stylus/cozy-ui/components/dialog.styl

Line 29 in 095af2a

height 90vh

). We probably want to let them grow as long as the content need it.

Empty views are not horizontally centered below 1024px

The Plan

Suite à l'atelier de jeudi et surtout à des discussions avec @kosssi et Claire, j'ai pris conscience que nous souffrons d'un manque d'alignement quant à l'évolution de cozy-ui, d'où un quasi status quo. L'objectif de cette issue est donc d'établir une vision claire pour tous et d'en discuter les détails d'implémentation.

Quels sont nos besoins ?

1. Arrêter de polluer nos composants applicatifs avec des className={classNames(styles['pho-truc-bidule'], styles['pho-machin-chose']} : l'un des procès fait à React est que JSX remettrait en cause le principe du "separation of concerns" en mélangeant HTML, CSS et JS dans le même fichier. Mais ce principe ne dit pas qu'il faut forcément séparer les langages, mais simplement d'isoler dans des portions de code séparées tout ce qui concerne un aspect particulier, une facette, du code. La bonne façon de faire cette séparation avec React est donc d'isoler dans des composants dédiés tout ce qui concerne l'aspect visuel de l'app (structure HTML requise + CSS, qui peut rester dans des fichiers séparés d'ailleurs) et d'utiliser ces petits composants visuels pour construire le markup des composants applicatifs. Cela améliorerait également la lisibilité du code.

2. Régler nos problèmes de layout : plusieurs bugs nous posent pb, notamment sous Safari. Je ne sais pas exactement où en est @GoOz dans ses tentatives de résolution de ces pbs, mais nous devons trouver une solution et surtout disposer enfin de composants de layouting communs. Je vous invite donc à partager vos opinions et surtout l'avancée de vos travaux respectifs sur ce sujet.

3. Disposer d'une bibliothèque de composants d'UI avancés (comprendre : embarquant du comportement et donc du JS en plus de l'aspect visuel, donc DatePicker, AutoComplete, etc...). Jusqu'à présent nous nous sommes débrouillés en implémentant nos propres composants (mais sans penser trop à l'accessibilité :/) ou en utilisant des paquets type react-autosuggest qui doivent être adaptés au thème cozy à chaque fois. Cela nous a pris beaucoup de temps, et certaines applis comme cozy-bank ou cozy-santé vont nécessiter des composants que nous n'avons pas encore.

4. Offrir à la communauté un moyen d'utiliser autre chose que React et/ou la lib de composants d'UI que nous pourrions choisir, et donc exposer par un moyen quelconque ce qui fait le thème cozy, afin que ces développeurs puissent aisément thémer la lib de leur choix.

Ma proposition

Je vois cozy-ui en 3 couches :

1. Le thème cozy : il nous faut exposer ce qui fait le visuel cozy sous forme de variables, afin de répondre aux besoins 3 et 4. C'est la condition pour pouvoir thémer facilement une lib externe de composants, quelle qu'elle soit. Et cela pourrait même nous permettre d'intégrer ce thème dans une appli Drive native si la nécessité s'en faisant sentir...

Ces variables doivent comprendre :

• les couleurs bien sûr, mais aussi tout ce qui concerne les polices,
• les styles de bordure, d'ombres portées, adaptées à différentes tailles standard (par ex. de boutons) : small, medium, large
• tout ce qui concerne le rythme vertical de la page : margins, paddings, line-heights, ...
  A titre d'exemple, voici ce à quoi j'étais arrivé avec Bosonic. C'est évidemment un boulot à faire en étroite collaboration avec Claire, et qui bien sûr ne se fera pas en un jour : il a d'ailleurs déjà été attaqué par @ptbrowne et il conviendrait de s'appuyer sur son travail. Bien que comme @CPatchane, l'avocat des standards que je suis préfèrerais une solution à base de CSS Variables (ce qui nécessiterait néanmoins de pouvoir aussi exporter ces variables sous forme de JS(ON) ), la solution JSON retenue me va très bien dans un premier temps.

2. Une lib de composants visuels pour répondre au point 1. Je parle ici de composants encapsulant des comportements "standards" en CSS, et qui ne contiennent donc pas (ou très peu et de façon exceptionnelle) de code lié au DOM (gestion d'events, ...) : ce ne sont pas des composants avancés type DatePicker que nous n'avons pas intérêt à recoder nous même. Rebass offre quelques bons exemples : un composant Circle pouvant être utilisé pour les avatars, un composant Arrow utile pour les menus, etc... On peut aussi imaginer un ensemble de composants implémentant des patterns spécifiques avec flexbox, comme CenteredPrompt, FeatureList ou Stream... les possibilités sont nombreuses, et c'est là où un master of CSS tel que @GoOz pourrait s'éclater je pense ;) Une bonne façon de lancer ce chantier serait de s'y mettre à plusieurs un vendredi aprem' pas trop chargé (milieu de sprint plutôt donc).

C'est également dans cette couche que viendrait nos composants de layouting. Mais il nous faut pour cela résoudre les pbs cités dans le point 2, et j'attends donc un état des lieux précis et des solutions possibles de la part des personnes directement concernées (@GoOz ? @ptbrowne ? @kosssi ? d'autres ?)

3. Une lib de composants d'UI avancés (c'est le besoin 3). Comme je le disais précédemment, inutile à mon avis de réinventer la roue, d'autant plus que c'est un boulot énorme pour faire bien et accessible. @kosssi lorgnait sur react-toolbox, et pour avoir suivi de près le monde des libs de composants d'UI ces dernières années, je pense également que c'est la meilleure solution aujourd'hui. Son seul défaut est qu'il impose pour l'instant d'utiliser sass pour créer son thème, mais gardons à l'esprit que ce ne sera jamais que du glue code entre nos variables et la lib, ce n'est donc pas si grave. Il n'est bien sûr pas envisageable (ni souhaitable) de transitionner toutes nos apps d'un coup vers cette lib, @kosssi se proposait donc de POCer son utilisation sur une appli encore à l'état d'ébauche, en l'occurence cozy-santé. Si la création d'un thème ne pose pas de pb particulier et dès que ce thème est propre et stable pour cozy-santé, nous pourrons l'intégrer dans cozy-ui et petit à petit dans les apps, selon la règle du boy scout.

Y a t-il des points de contention que j'aurais omis de mentionner ? Certains ont-ils des oppositions formelles ? J'attends vos réactions à cette proposition, mais n'oubliez pas de lui donner 5 minutes ;)

Use Bosonic for components

The Bosonic project aims to be a nice components library, base on the standards WebComponents, and use some shinny feature such as CSS variables for tweaking and theming.

We should rely on it to declares our reusable components, such as modals, pickers, forms inputs, etc.

Remove extra padding for sidebar

It could be great to remove the padding-right of 10% on the nav component (and put it on nav-item if needed). For me, this is some useless space which can't be used.


In this last picture, the first title would be on one line without this space.

Add a "mixed" state for checkboxes

We should add a aria-checked support for the 3 defined values true, false, mixed (see https://www.w3.org/TR/wai-aria/states_and_properties#aria-checked) here : https://github.com/cozy/cozy-ui/blob/master/src/stylus/cozy-ui/app/forms.styl#L73-L84.

This way, we can support the checkbox as well as the aria-checked state.

Tip: this one shuld be converted to webcomponent when we add support for them.

`<Icon />` component

I have done an Icon component for the MAIF project.

Example usage :

<Icon icon='out' />
<Icon icon='home' />
<Icon icon='phone' />

The icon's color comes from the surrounding text and you can change it via CSS.

I see that in Drive, you use background-images to display icons. The benefit I see of this approach is that you can change the icon of a button without changing the HTML/JSX code. The downside is that it is not possible (?) to color the image from the surrounding text.

The <Icon /> approach is very similar to the Font-Awesome way of doing things so external developers may be familiar with it, and you do not need to add CSS for your component to display an icon. This allows for less custom code, more reliance on cozy-ui and more coherent designs.

What do you think of this component and do you think it could be an addition to cozy-ui ?

[EDIT]
When I say "icon", I am talking about this kind of icons :

Not this kind

Put a Spinner in a Button

Hi,

I would like to put a Spinner in a Button.
My first guess was to add it directly as children:

<Button onClick={onClick}>
  <div>Load More {isLoading && <Spinner color="white" />}</div>
</Button>

But the children props is defined as a string. Should it be changed? Or should I changed my way of working?

cf. https://github.com/cozy/cozy-ui/blob/master/react/Button/index.jsx#L18

Notifications center

System may offer a notification center that can be displayed as a simple panel.

2 small bugs on the storybook

• the paperplane icon is not shown
• the grey and white spinners are blue

Modal makes the window scroll to top

When a modal opens-up on a scrolled down window, the window scrolls up to the top.

Get a ref on the modal

In cozy-edf, I needed to get a ref on the .coz-modal part of the Modal to display the inter-app modal in it. Since there is no way to attach a ref callback in the Modal, I had to replicate the structure of the Modal.

https://gitlab.cozycloud.cc/labs/cozy-edf/blob/master/src/components/IntentModal.jsx

What do you think of a modalRef prop to be added to <Modal /> ?

Popover / Modals

Create frameworks agnostics and accessibles components likes popovers and modal boxes.

Those plugins must come with their default styles (header / footer / buttons / etc) to keep appearance consistent.

Un bout de doc pour la largeur minimale des modales / iframe ?

Hello !

J'ai recontré un soucis sur l'app "Mon logis", un intent est chargé dans une modale, qui a été fixée a 700px de large par le développeur. Le contenu passe donc systématiquement en mode mobile dans cette modale.

Est-ce qu'on pourrait ajouter à la doc les recommandations pour des modales qui seraient en accord avec nos breakpoints, pour éviter ce genre de soucis ?

Merci !

Base CSS framework?

Should we use a base CSS framework? If yes, there is only one good candidate: http://www.knacss.com/

Lato font on Styleguidist

Add Lato font on Styleguidist since otherwise it feels different than our apps.

Dark mode in Firefox

We should have default white background color and black text color to avoid being overwritten by browser styles. In the dark mode of Firefox, the background will be #000 by default and text will be white. So I would suggest to add these default styles directly on html:

html {
  background: white;
  color: black;
}

Icon does not forward handlers

Icon should forward at least onClick and maybe all its props to the underlying <svg /> it is a shortcut component.

Font fighting on some elements

normalize.css sets the font-familyof certain elements, for example buttons. In cozy-ui, we rely on inheritance to propagate the default font.

This means that buttons with no extra font-declaration get the default sans-serif instead of our Lato. There are actually a few places in our v3 UIs where the wrong font is used, most notably the selection bar in files.

Not sure of the best way to fix this. Should we just declare the font-family on a lot more elements in the default styles? Ping @GoOz and @m4dz for input.

Need webpack to import cozy-ui ?

We need to have webpack.config.cozy-ui.js files. I think it should not be the responsibility of an application to know how cozy-ui is coded so that it should know which loaders are necessary.

One solution would be to ship a built version on npm.

It would then be hard for people hacking on cozy-ui through another application to use it since they would have to build each time they make a change. Maybe cozy-ui should have a webpack file ready for people linking directly and wanting to hack on cozy-ui while they develop their application. This way, a user wanting to hack on cozy-ui could do:

const webpackConfig = merge(
  ...,
  ...,
  require(`cozy-ui/webpack`)
)

temporarily in their file ?

What do you think ?

Discussion about that : webpack/webpack#378

property withCross of the Modal

I open this issue to discuss about this property which is currently badly implemented for me according to these points:

• The naming, withCross just means nothing for me, it would be preferable to have something named like withClosingButton IMHO
• The behaviour. For me, this property should just decide if the modal should display a closing button or not and THAT'S ALL. I really think that this property should not affect the key listener and the click outside listener used to close the modal. For this specific need, we could use a better property named disallowClosing which is more appropriate for here to my mind.

#my2cents

Intelligent pickers

We need intelligent pickers for many selectors:

• date
• time
• datetime
• color

Those must display localized, intelligible contents (such as a formatted date string) and display a popover picker when clicked.

Selector component ?

We have this component in Bank and Santé. Current behavior :

• Menu should take all screen on mobile
• Menu should be opened from the selector on Desktop
• It should have a small chevron to the right
• There should be an Overlay when opened

So it seems it is quite like a Menu except that it has an overlay and a different behavior on mobile. What do you think @GoOz ?

I am open for a different name.

Afficher les storybooks dans la documentation en ligne

Overflow in iOS

When you scroll from the bar at the bottom, you can scroll the html container and then the layout is broken.

<select> font is sans-serif

Previously 's font was Lato. It is no longer the case.

Spinner

We use JS spinners, because they are convenient (and easily customizable). But a CSS version would be very nice!

CSS shouldn't display svg icons in background, but only change their color, size, etc

Naming convention

I started to read about managing CSS properly, but I haven't pushed it yet. I heard of "BEM" methodology, and siblings. Do you have any opinion on that kind of methodology? Do you think it would be worth it to learn and use one?

Long nav link causes overflow from hover background

Add className option on Spinner

In order to allow giving special style to a spinner so you don't have use tricky selector like [class^=coz-spinner]

Récupérer facilement les couleurs

Actuellement on ajoute dans chaque projet ses propres variables JS pour les couleurs alors que l'on a un référentiel dans palette.styl.

Nous devrions pouvoir récupérer facilement une variable :

import palette from 'cozy-ui/palette.json'
import { Icon } from 'cozy-ui/react'
<Icon icon='album-add' color={palette['cool-grey']} />

Proposition:

1. Continuer comme on fait
2. Créer rapidement des variables dans un fichier JS (du coup duplication des variables js/stylus)
3. Créer un palette.json avec les variables puis les importer dans stylus et dans un fichier JS

List cell

List are common in use. We may have a component that can handle lists (creation / management), focusing on perfomance and cell-reuse.

Mobile browser chrome does not disappear when we scroll

The UI of the browser must disappear when we scroll.

font-size mixin

font-size is redefined here : https://github.com/cozy/cozy-ui/blob/5e092f964de2c2268a004250bac5eab019a5d5a0/stylus/tools/mixins.styl

It basically convert the px in em so that your px are dependent on the root font size. The primary goal dixit m4dz was to help developers that do not know about rem to have a design that was responsive and reactive to the change of root font size.

I think it is a very surprising behavior of cozy-ui, that rem fit this goal perfectly, and it does not teach people how to use properly rem.

I would be in favor of removing this mixin.

Add a styleguist link for components

Add a direct link to the component styleguidist page in the component readme.

Font smoothing

I think it would be good to add that to the default styles.

body {
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: antialiased;
}

To be clear : when the font is bolder (and ugly), font-smoothing is not active.

Transfer selected item style from Cozy-Drive

See: cozy/cozy-drive@25d6bc6

Intent components

Components that can open intents with default styling would be useful.

• IntentButton

Already been implemented in Bank and Drive

$ cozy   rg 'IntentButton'
bank/src/components/IntentButton/index.js
1:import IntentButton from './IntentButton'
4:export { IntentButton }
6:export default IntentButton

bank/src/components/IntentButton/IntentButton.jsx
10:class IntentButton extends React.Component {
50:export default IntentButton

drive/src/drive/components/Intent.jsx
9:class IntentButton extends React.Component {
74:export { IntentButton }

• IntentModal

Should take the 80% of the screen in desktop and 100% on mobile

See https://gitlab.cozycloud.cc/labs/cozy-bank/blob/master/src/components/IntentButton/Intent.styl

Starting point

Not an issue but information:

An attempt to make things more consistent between Cozy apps was to provide this stylesheet in every application. https://github.com/cozy/cozy-files/blob/master/client/app/views/styles/_cozy.styl
That way we made all the cozy buttons behave the same way. They are not really pretty but it makes easier for users to learn the Cozy apps.

doc for Alerter + easier usage

There is no doc for the Alerter component in styleguidist.

Using mixins and default stylesheet, not just default stylesheet

Bootstrap comes with two versions: a CSS stylesheet and a LESS version. There are also port for other CSS pre-processor.

I think it's a good practice to build first a bunch of mixins, then to build a default stylesheet based on them: you can use the default style, and customize your own style with the mixins.

Also it makes HTMl easier to read, because you use semantic class names (your own) rather than ".cozy-btn", and so on.

Exports from react

At the moment in my app, I have:

import Modal, {ModalContent} from 'cozy-ui/react/Modal'
import Button from 'cozy-ui/react/Button'
import {Tabs, TabPanels, TabPanel, TabList, Tab} from 'cozy-ui/react/Tabs'

I think it would be better if we could do :

import {
   Modal, ModalContent,
   Tabs, TabPanels, TabPanel, TabList, Tab,
   Button
} from 'cozy-ui/react'

This way we hide the internal structure of cozy-ui.

Hero style

I think it would be good to standardize the way we do onboarding screens. We have several screens like that in labs apps. Do you also have that in Photos, Drive ?

Introducing .hero, .hero__icon, .hero__title, .hero__subtitle could be a good way to do that.

ModalCross can take a class as props to override default style

ModalTitle, ModalContent, ModalSection can take a classname props to override default style, but not the ModalCross.

It can be usefull to have this pros in the ModalCross too.to avoid this kind of trick to adjust styles of this cross.

    [class*="coz-btn-modal-close"]
        top: 4px
        right: 4px