npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

z-release-from-pipeline

v0.0.4

Published

A suite of React components, adhering to Allica Bank's Design System

Downloads

12

Readme

@allica/ui-react

A suite of React components based on the Allica Design System, that enables teams within Allica Bank to build consistent user interfaces

Scope

It is important that the scope of this library is constrained to only those components and utilities that implement the small building blocks of the Allica Design System. These building blocks can be consumed by product applications in order to build application specific components and pages. Application specific components should not be added to this library.

Component designs (Figma)

Getting Started

Install in a project

The library is a private npm package, hosted on Azure. In order to install and use the library you must first set up access to Azure artifacts, usually with Personal Access Token, and then setup your project .npmrc (note this is different from the user .npmrc mentioned in the Azure artifacts setup)

Set up Personal Access Token (PAT)

Follow the steps here, under 'Project setup', making sure to follow the correct steps for your operating system.

Set up .npmrc

In the root of your project (same level as package.json), if not already created, create a .npmrc file

touch .npmrc

and add the following -

@allica:registry=https://pkgs.dev.azure.com/AllicaBankLtd/Allica_Web/_packaging/allica_web/npm/registry/

Install the package

To install the package, run -

npm i @allica/ui-react

Install peer dependencies

This component library relies on some packages that your application needs installed as dependencies. These packages do not come packaged automatically. To install the required peer dependencies, run -

npm i react@18 react-dom@18 @chakra-ui/react@2 @emotion/react@11 @emotion/styled@11 framer-motion@7

Optimize your bundle size

Given this library relies on Chakra UI and it's dependencies, its important to pay attention to the bundle size of your application after installing the above dependencies. Your application should look to use optimizations such as tree shaking, minification and compression as a minimum.

Storybook

The library contains a Storybook of all the available components. Currently storybook is only available locally. To view Storybook, run -

npm run storybook

Using the library in the project

Theming

Once you have the library installed in your application, you need to wrap your components with a ThemeProvider. This will apply the Allica 'theme' to the components consumed from this library, and also any further Chakra-UI components. You also need to import the fonts. You can do something like -

import { ThemeProvider } from '@allica/ui-react'
import '@allica/ui-react/dist/esm/fonts.css';
...
return (
    <ThemeProvider>
        <App />
    </ThemeProvider>
)

Now you can apply theme values to components, in order to get the predefined size / color / variant of component etc

e.g. for a Text component, with a size '02' and colour 'text-1' (as per design language)

import { Text } fron '@allica/ui-react';
...
return (
    <Text size={'02'} color={'text.1'}>Example</Text>
)

The various values that are used in the theme, such as colors, fonts, sizes, spacing and more, can be found here

Typescript support ( @allica/ui-react v2.7+)

In order for typescript to know about the available theme tokens, you can add the following script to your project, which will generate theme tokens based on the Allica theme -

"gen:theme-types": "npx chakra-cli tokens node_modules/@allica/ui-react/theme ",
"dependencies": "npm run gen:theme-types",

note - dependencies script is optional, but is a predefined npm script that will run when node_modules are updated, useful for automatically generating theme tokens

More on theming in Chakra-UI's docs

Contributing

Work items for new component designs, implementation and any bugs found in the component library should be tracked in Jira.

Component discovery

In order to define what is a viable component that should be placed in this library, there is a discovery process that needs to be followed to ensure we are only adding necessary, useful components, without creating duplicate components that solve for the same UX use case.

Process - TBD / Work in Progress

At least for now, all component requirements and ideas should be discussed with the Design team, creating Jira work items as necessary to account for design and engineering effort

Jira

TBC - Currently work is being tracked on the Allica Engineer board, but will probably move to the Design board

Workflow Guidelines

Directory structure

In order to ensure consistency across components in the library, each component, where possible, should be placed inside a new directory inside src/components, named as per the component name. The directory should have the following files added and completed in order to be treated as 'done' -

  • component file (e.g. button.tsx) - the React component and any component logic
  • styles file (e.g. button.styles.ts) - any relevant internal styling for the component
  • theme file (e.g. button.theme.ts) - component specific theme values
  • test file (e.g. button.spec.tsx) - Unit tests using jest and @testing-library/react
  • storybook file (e.g. button.stories.tsx) - stories of the components, showcasing the various states and variants of a component
  • index file (e.g. index.ts) - A file that represents the public API for the component, ensuring only the intended components, functions etc get exported to the consumer.

e.g.

src
    /components
        /button
            button.tsx
            button.styles.ts
            button.theme.ts
            button.spec.tsx
            button.stories.tsx
            index.ts <!-- exports Button component
        index.ts <!-- exports all components

Component structure

Without being too prescriptive, but for some consistency, loosely follow a structure as below -

(button.tsx)

import { FC, PropsWithChildren } from 'react';

export const Button: FC<PropsWithChildren> = ({ children }) => {
    const handleClick = () => {...}

    return (
        <button onClick={handleClick}>{children}</button>
    )
}

(src/components/button/index.ts)

export { Button } from './button';

(src/components/index.ts)

export * from './button';

Note - there is no benefit in using export default, as all components will need to be named in order to be exposed to the consuming application, therefore it removes the need to alias an export like -

(src/components/button/index.ts) - (not recommended)

export { default as Button } from './button';

Testing

We are currently using jest and @testing-library/react for unit testing

Build

Before your components can be consumed by an application, you need to build the library. The build process output two formats - esm ECMAScript Modules and cjs CommonJS

esm is used by your consuming React application and ran in the browser.
cjs is used by your unit tests, until jest offers first class support for esm (still experimental)

To build the library, run -

npm run build

Testing / Running the library locally

In order to test out your new component, or changes to an existing component, you should do this before publishing the library. One way to accomplish this is to use npm link

Uninstall @allica/ui-react from your application

npm un @allica/ui-react

In a terminal for this component library, build the library (if not already built), and use npm link

npm run build
npm link

In your application terminal, link the library

npm link @allica/ui-react

!! IMPORTANT !!

When you are done testing, be sure to reinstall the real library -

npm i @allica/ui-react

Git Commit / Git Push

This library is following the conventional commits standard. This library will preinstall a git commitmsg hook via husky to ensure commit names follow this standard. It is important as the automatic version bumping mechanism (commit-and-tag-version) uses the conventional commit messages to determine the next version automatically. (major, minor, patch).

If working on multiple features / components, please commit each one separately so that each commit only contains a single feature, and the commit message accurately describes that single change.

an example bugfix commit in the terminal looks like -

$ git commit -m "fix(Button): fix button click handler
>
> refs: AB-123"

producing -

fix(Button): fix button click handler

refs: AB-123

Note, please use the name of the component/feature, in this case Button, as the scope in the commit message, as this gets used in the changelog generation. For adding JIRA ticket ids, please add them to the body of the commit description as shown.

Squashing commits

Please only squash commits so that a single commit contains a single feature. It is OK to have a pull request with multiple commits, where each commit represents a single feature. This is important for accurate changelog generation.

Raise a Pull Request

Once you have committed and push your changes, please raise a pull request.

Note

  • it is common for a single pull request to have multiple commits where there has been multiple component updates
  • we haven't yet bumped the version of the library yet, this comes next.

Create a Release

Once all the changes have been merged into the main branch that are targeting the next release, you can now generate a new changlelog and bump the version, ready for a Release Pull Request.

In a feature branch that has the latest from master (this can be the branch from the previous step), Run -

npm run release

this will -

  • bump the version in the package.json and package-lock.json according to previous commit messages
  • create a new git tag based on the new version
  • add commit information to the CHANGELOG.md as release notes, since the last release.

Then push your changes, making sure to also push the new tag

git push --follow-tags

Now create another pull request

Publishing

Once the Release pull request has been approved and merged to the main branch, you can now publish to Azure Artifacts (our private NPM repo)

In the branch that contains your latest changes, you can run -

npm publish (Use pipeline, instead of this command from your machine)

Note, the prepublishOnly npm script will ensure your local machine has the correct release artifact built before it runs the npm publish command

Pipeline

Getting ready