@wapo-fusion/elex-cal-beta v0.0.5

Fusion features as NPM modules (POC).

What?

This repo lays out a proof of concept for handling our cross team fusion features as separate npm modules in isolated git repositories

Why?

Coordination

Git history, Deployment scheduling, and code organization are all easier on smaller scales. Single monolithic repositories are hard to scale to many many developers.

Discoverability

Code reuse just for the sake of being "DRY" means that you spend more time looking for the getCookie utility than it would have taken you to write your own. Yes, we don't need a million different getCookie implementations, but getting a cookie is also not a closely guarded company secret, It's ok for teams to have their own utilities in locations where it make sense for their particular project. This benefit falls naturally from decoupling our repositories and managing them separately.

Explicit vs Accidental Code reuse.

This last point is related to the ones preceding it. We want to share code in an explicit and deliberate way instead of doing so accidentally. A good example would be sharing our design system. A bad example might be sharing a single Tracking or Analytics component between multiple teams with vastly different analytics requirements. We want our different teams to adhere to the same design priniclples across most projects and teams. We may not want every team to inherit the Analytics / Tracking requirements on normal articles. By separating our repositories we can isolate the things that we don't want to accidentally share and centralize the things we do want to share.

How?

This repo uses storybook as a means of component development. It mocks the fusion environment by mocking commonly used tools like useContent or Consumer. It comes with a build script that exports 2 files components and content. They contain components and content sources respectively. All users of this repo must do is place an index.js entriy point in both directories that exports (using named exports) the components or content sources. The plan then is that the fusion team will consume these npm modules and set them up appropriately within the wp-fusion project

Getting started

Development

Start story book.

Most development is intended to be done inside story book. This repository already contains a working example using a hypothetical "elections calendar" fusion feature. Simply use npm run story book in order to see it!.

A bit about directory structure

If you peer into the src folder you'll see a components folder where there is an index.js file as well as index.stories.js, the former containing our actual calendar component and the latter containing our storybook stories. If story book is running making changes to our calendar should be immediately reflected using storybook's hot reloading.

The possibilities are many here. The only requirement for compatibility with fusion is that an entry point exists (index.js) in both the components directory and the content-sources directory. Both of these files can export as many members as you like

Build and publish.

Once you have made some code changes and are ready for another release you'll need to build and publish your code.

npm run build

Then increment the version number in package.json to the appropriate version number (use semver!).

npm publish

You've now published a new version of both your features and your content sources. They can be imported in fusion in this manner:

// components/feature/elex/calendar.js
import { Calendar } from "@wapo-fusion/elex-cal-beta/components";

export default Calendar

// content/elex-calendar.js
import { calendar } from "@wapo-fusion/elext-cal-beta/content";

export default calendar