2.0.6 • Published 8 months ago

@bloomreach/brie v2.0.6

Weekly downloads
-
License
-
Repository
-
Last release
8 months ago

BRIE

About

Brie is a library and collection of UI components meant to be used within all the brXM frontend applications, with the ultimate goal of building a consistent user experience.

See more at BRIE Introduction storybook for general information.

Core contributors

Working with brie in your local app

When working on an application you will likely find yourself in the situation where you need to also make changes to a brie component. There are two ways to test local changes made to the library.

The simplest option is make your changes in the component and test them via the existing Storybook integration. This is best suited for testing the component API and other basic interactions.

Another way to test changes is to test the component directly within the context where it is being used, for example as part of one of the existing FE applications. This is possible out of the box since the brie project folder is mapped to the dependency within the FE application. This is configured via lerna or yalc.

Component development practices

Please read this section before contributing to the library. Any addition to the library must adhere to these practices for consistency, readability and maintainability reasons.

Development practices

// TO BE ADDED

Testing

When adding changes for any component part of the library it is mandatory to have them covered by tests. These tests need to be meaningful and developed with extensive coverage in mind. By their nature components will be used in a wide variety of scenarios and so extensive coverage is crucial in order to avoid unpredictable results.

As a rule of thumb, use the followings testing practices:

  • Snapshot testing
    • Prefer snapshot testing over unit testing because it allows you to reduce the time spent writing often large amounts of testing boilerplate code
  • Unit testing
  • No integration testing
    • Do not test components interacting with each other, this should be tested within the application that implements the interaction

What should be covered by tests?

  • Snapshots of the final rendered component in the various meaningful states
  • Component class methods
    • If a method has a single branch then they are usually already covered by snapshot tests
  • Asynchronous events
    • click, hover, blur, etc.
    • promises

Versioning strategy

// TO BE ADDED


Copyright 2022 Bloomreach. All rights reserved.

2.0.4-alpha.1

8 months ago

2.0.4-alpha.2

8 months ago

2.0.3

8 months ago

2.0.0-alpha.3

9 months ago

2.0.2

9 months ago

2.0.0-alpha.4

9 months ago

2.0.4

8 months ago

2.0.6

8 months ago

2.0.0-alpha.0

9 months ago

2.0.0-alpha.1

9 months ago

2.0.0-alpha.2

9 months ago

2.0.1

9 months ago

2.0.0

9 months ago

2.0.5-alpha.1

8 months ago

1.1.0

11 months ago

1.0.2

1 year ago

1.0.4

1 year ago

1.0.3

1 year ago

1.0.1

1 year ago

1.0.0

1 year ago

0.0.36

1 year ago

0.0.36-alpha

1 year ago

0.0.30

2 years ago

0.0.31

2 years ago

0.0.32

2 years ago

0.0.33

2 years ago

0.0.34

2 years ago

0.0.35

2 years ago

0.0.29

2 years ago

0.0.22

2 years ago

0.0.23

2 years ago

0.0.24

2 years ago

0.0.25

2 years ago

0.0.26

2 years ago

0.0.27

2 years ago

0.0.28

2 years ago

0.0.21

2 years ago

0.0.20

2 years ago

0.0.19

2 years ago

0.0.18

2 years ago

0.0.17

2 years ago

0.0.16

2 years ago

0.0.15

2 years ago

0.0.14

2 years ago

0.0.13

2 years ago

0.0.12

2 years ago

0.0.11

2 years ago

0.0.10

2 years ago

0.0.9

2 years ago

0.0.8

2 years ago

0.0.7

2 years ago

0.0.6

2 years ago

0.0.5

2 years ago

0.0.4

2 years ago

0.0.3

2 years ago

0.0.2

2 years ago

0.0.1

2 years ago