DEV Community: Azizi Yazit

From Scrum to Extreme Scrum: How to Supercharge Agile Teams

Azizi Yazit — Sun, 05 Oct 2025 10:32:01 +0000

Introduction

Scrum has become the go-to framework for Agile teams worldwide. Its ceremonies, roles, and artifacts provide structure and rhythm, enabling teams to deliver value in short, iterative cycles. Yet many organizations find themselves frustrated—daily stand-ups often feel like status updates disconnected from real changes in the codebase, sprint reviews frequently deliver feedback too late, end-to-end automation is skipped, and the promise of agility gets buried under rigid processes.

That’s where Extreme Scrum (XS) comes in. Born from the need to address these gaps, XS builds on the foundations of Scrum and strengthens them with proven practices from Extreme Programming, Trunk-Based Development, Component-Driven Development, and Acceptance Test–Driven Development. The result is a methodology designed to maximize collaboration, accelerate feedback loops, and elevate code quality to the next level.

In this article, I’ll share how XS transforms traditional Scrum into a high-impact framework—replacing daily stand-ups with daily code reviews, embedding continuous automation and testing into the workflow, and fostering closer collaboration between developers, automation engineers, and product owners. If you’ve ever felt that Scrum alone isn’t enough to supercharge your team, XS may be the solution you’re looking for.

Scrum:

Extreme Scrum (XS)

Daily Code Standup – Driving Continuous Integration

In Extreme Scrum (XS), the traditional daily stand-up is replaced with a Daily Code Standup. Instead of giving status updates, the team reviews the actual code changes committed in the last 24 hours. This shifts the focus from what each person is doing to what has changed in the product.

Daily Code Standup works hand-in-hand with Trunk-Based Development (TBD). Since every developer commits small, incremental changes directly to the main branch on a daily basis, the team always has a single, up-to-date codebase to review. This ensures that discussions are grounded in the latest, working code and that feedback loops stay extremely short.

Key benefits of a Daily Code Standup:

Code-centric discussions – Conversations are grounded in real, recent commits rather than abstract updates.
Early feedback – Potential issues, design flaws, or duplication are caught within a day.
Team-wide pair programming – Everyone gains visibility into the evolving codebase, similar to continuous peer review.
Higher accountability – Each developer explains their commits, promoting ownership and shared understanding.

By combining Daily Code Standups with Trunk-Based Development, XS creates a rhythm of continuous integration, immediate feedback, and collective ownership—ensuring faster learning, higher quality, and stronger collaboration across the team.

Pair Programming vs. Team-Wide Pair Programming

Aspect	Pair Programming	Team-Wide Pair Programming (Extreme Scrum)
Who is involved	2 developers (Driver + Navigator)	Entire team reviewing each other’s daily commits
Focus	A single feature or task	The entire evolving codebase
Knowledge sharing	Between the two developers	Distributed across the whole team
Feedback loop	Immediate but limited to the pair	Immediate and collective, during Daily Code Standup
Accountability	Shared between two	Shared across the entire team
Scalability	Works well for small tasks	Scales to teams, ensures everyone stays aligned
Analogy	Two people writing code together	Everyone “pairing” with everyone else, every day

By scaling the principles of pair programming to the entire team, Team-Wide Pair Programming ensures broader knowledge sharing, collective ownership, and higher code quality than traditional pair programming alone.

Desk Checks

In Extreme Scrum (XS), a Desk Check is a lightweight, mini–Sprint Review that occurs frequently during the sprint rather than only at the end. Desk Checks ensure that feedback flows continuously, reducing the risk of late surprises and strengthening collaboration between developers, Product Owners, and Testers.

There are two types of Desk Checks:

1. Desk Check with the Product Owner (PO) – Driving Early and Continuous Feedback

This session focuses on validating direction, usability, and value. Instead of waiting until the sprint review, developers showcase work-in-progress slices of a feature.

Example: If the task is Developing a Login Page, the developer can first show the layout and alignment of text fields and buttons, then later demonstrate validation rules for username and password.
The PO provides early feedback on design choices, interactions, or copy, ensuring the product evolves in the right direction.

This incremental feedback loop saves time, reduces rework, and creates a tighter connection between developers and product stakeholders.

2. Desk Check with Tester / Automation Engineer – Driving Continuous Test Automation

This session centers around quality, testability, and automation readiness. Instead of waiting for a “finished” feature, developers and testers treat each piece of functionality as a puzzle of the feature that can be reviewed and tested incrementally.

Example: For the Login Page puzzle, one Desk Check could focus only on password validation logic.
The Automation Engineer can start a contract testing discussion with developers, covering details like data attributes to be used in Cypress scripts or other automation frameworks.
Since code is committed daily (Trunk-Based Development), Automation Engineers can immediately begin scripting automation tests for each puzzle, rather than waiting for the full feature to be complete.

Benefits:

Faster automation readiness.
Earlier detection of design/testability issues.
Continuous collaboration between developers and testers, mirroring a team-wide pair programming mindset.

Continuous Automation Testing

In Extreme Scrum (XS), automation testing is built into the process from the very beginning. It starts at EPIC grooming, where the team defines the feature holistically along with its Acceptance Criteria. From there, the EPIC is broken down into smaller stories through a process called Feature Breakdown.

This approach is inspired by the Test-First philosophy from Test Driven Development (TDD) in Extreme Programming. While TDD focuses on writing unit tests before implementation, XS extends this mindset to the feature and acceptance level—ensuring that testing considerations guide development from the start. In other words, XS is not strictly TDD, but it embraces the same principle: tests come first, code follows.

Each EPIC carries an Acceptance Details Test (ADT) for end-to-end (E2E) coverage, derived directly from its Acceptance Criteria. Likewise, each story is defined with its own ADT for Component Testing. These tests are written in Gherkin (BDD) format:

Given [initial context]  
When [event occurs]  
Then [expected outcome]

All stories with defined ADTs are stored in the Acceptance Details Testing Backlog, and it becomes mandatory that items in the Sprint Backlog are selected from this backlog. This ensures testing is never an afterthought but an integral part of the development cycle.

By having ADTs defined before coding begins, both Developers and Testers are aligned on the test cases. As development starts, Testers can work in parallel by scripting automation tests against the ADT. During Desk Checks, Developers and Testers review, refine, and enhance the ADTs together.

When subsequent stories (or “puzzles” of a larger feature) are developed, Desk Checks validate them against the automation scripts already written for earlier stories. This creates an immediate safety net, ensuring no breaking changes slip through.

To make this process smooth and incremental, XS leverages Trunk-Based Development techniques like:

Branch by Abstraction – Allows developers to split a story into multiple incremental commits (abstractions and implementations), enabling handover in small, manageable steps.
Feature Toggles – Let developers safely commit incomplete features to the mainline. Incomplete functionality is hidden from end users but exposed via toggle flags so Testers can enable it for automation scripting.

This approach ensures that the mainline remains deployable on demand, with no risk of unstable or partially complete features disrupting production—while fully embracing the test-first philosophy to drive quality and agility.

XS Test-First vs TDD: What’s the Difference?

While Extreme Scrum (XS) borrows the test-first philosophy from Test-Driven Development (TDD), the two approaches operate at different levels:

TDD (Extreme Programming)
- Focuses on unit-level tests.
- Developers write a failing test first, then implement code until the test passes.
- Cycle: Red → Green → Refactor.
XS Test-First
- Focuses on feature and acceptance-level tests.
- Tests are defined as Acceptance Details Tests (ADTs) before coding begins.
- Both Developers and Testers collaborate on automation scripts aligned with business outcomes.

👉 In short: TDD validates correctness of code at the micro level, while XS validates correctness of features at the macro (business) level—both driven by the same philosophy: tests guide development, not follow it.

XS Test-First Flow

flowchart TD
    A[EPIC Grooming] --> B[Feature Breakdown → Stories]
    B --> C[Define Acceptance Details Test (ADT)]
    C --> D[Developers & Testers Work in Parallel]
    D --> E[Desk Checks: Review & Refine ADTs]
    E --> F[Automation Scripts Validated]
    F --> G[Automation Safety Net (No Breaking Changes)]

Process Retrospective – Driving Objectivity and Continuous Improvement

In Extreme Scrum (XS), the Process Retrospective is designed to focus squarely on the process itself—not on individuals or vague feelings. The purpose is to evaluate whether each practice is working well, needs improvement, or requires replacement.

The retrospective documentation is structured into clear sections for every XS practice, such as Daily Code Standup, Desk Checks, Acceptance Details Tests (ADT), Trunk-Based Development, and others. Participants provide feedback only within these defined sections, ensuring discussions remain targeted and constructive.

This differs from a traditional Scrum retrospective, which can sometimes drift into personal complaints, emotional venting, or even finger-pointing. While those conversations may have value, they often risk lowering team morale and derailing focus.

By anchoring the retrospective in process evaluation rather than personal critique, XS promotes:

Objectivity over subjectivity – Teams assess whether the practice works, not whether a person did something wrong.
Continuous tuning – Each iteration allows processes to be refined, adjusted, or enhanced.
Shared ownership – Everyone contributes to shaping the methodology, creating buy-in and alignment.

Over time, this approach builds a culture of systematic improvement, where every process is tuned until the team is satisfied—and where retrospectives serve as a driver of progress rather than a drain on momentum.

Traditional Scrum Retrospective vs XS Process Retrospective

Aspect	Traditional Scrum Retrospective	XS Process Retrospective
Focus	Team feelings, individual performance, general issues	Processes, practices, and workflows
Discussion Style	Open-ended, may drift into personal complaints	Structured, limited to predefined process sections
Feedback Timing	Typically at the end of the sprint	Continuous, process-focused throughout the sprint
Accountability	Can feel personal, sometimes leads to blame	Objective, centered on practices rather than people
Improvement Approach	Subjective suggestions	Systematic tuning of processes based on observations
Outcome	Insights may vary; risk of lowered team momentum	Actionable process improvements; momentum maintained
Collaboration	Team reflects together, may focus on issues	Everyone contributes to process refinement and alignment

Example: A Day in Extreme Scrum (XS)

Here’s how a typical day looks for an Extreme Scrum team:

Daily Code Standup (Continuous Integration)
- Team reviews commits from the last 24 hours.
- Focus is on the mainline health, not status updates.
- Issues (conflicts, failing tests, duplication) are identified immediately.
- The team uses Branch by Abstraction and Feature Toggles to keep trunk stable.
- Everyone gains visibility into evolving code during the Daily Code Standup.
Desk Check with the Product Owner (Continuous Feedback)
- Developer showcases a work-in-progress slice of a feature.
- PO provides early feedback on usability, flow, and alignment with business needs.
- Example: reviewing just the form layout or validation logic of a login page.
Desk Check with the Tester / Automation Engineer (Continuous Automation Testing)
- Tester and developer review Acceptance Details Tests (ADTs).
- Begin scripting automation tests in parallel (e.g., Cypress).
- Validate contract testing details (e.g., data attributes, APIs).
- Ensures each “puzzle” of the feature can be tested early.
Continuous Integration Pipeline
- Every commit triggers unit, component, and E2E tests.
- Earlier ADTs act as an automation safety net, ensuring no regressions.
Continuous Delivery Mindset
- Mainline is always deployable on demand.
- PO or stakeholders can enable toggled features to validate progress instantly.
- Value is delivered continuously, not just at sprint reviews.

Key Takeaway

A day in XS is not a rigid sequence of ceremonies but a continuous cycle of code, test, and feedback.

It keeps everyone—Developers, Testers, and Product Owners—aligned around working software and business outcomes, every single day.
Thanks for reading! If you enjoyed this, follow me for more dev process experiments.

Higher Order Component enabled by Ivy

Azizi Yazit — Tue, 17 Dec 2019 16:47:29 +0000

Higher Order Component - HOC

A higher-order component (HOC) is an advanced technique for reusing component logic. Concretely, a higher-order component is a function that takes a component and returns a new component.

Angular HOC

Below is sample HOC withTheme and obviously the code received the component, insert the theme data and return decorated component. Annotated or attached the HOC to the class component is called meta-programming using typescript decorator.

Meta-programming is a technique by which you can modify the code dynamically at runtime.

And below is the HOC usage

Be creative

Ivy is enabler, it enabled HOC and Meta-programming. Be creative, there's so many use-cases can be cater by HOC.

Here is an example of enabling CSS-in-JS using HOC withStyles

And here is some ideas:

withAuth

return auth data if user have been authenticated

withRouter

return a router data

withProvider

return provider reference

Code repository

Check the codes here https://github.com/abumuawiyah/ng-ivy

Angular theme provider

Azizi Yazit — Sat, 24 Aug 2019 18:04:18 +0000

Providing a theme provider is a must in a component library. All components should be able to gain access to the Theme Object. This includes palettes, spacings, sizings, and more.

In Angular, providing the theme provider is easy to accomplish as Angular has this ability out of the box.

In this post, we are using forwardRef and ngTemplate.

forwardRef

Basically, forwardRef is a function that captures a class reference into a closure. By using forwardRef, we can access the component reference and use it in other components.

constructor(
  @Inject(forwardRef(() => YourComponentName))
  private yourComponentName: YourComponentName
) {}
~~~{% endraw %}

## ng-template

{% raw %}`ngTemplate`{% endraw %} can use properties of its parent context and can have its own private context.{% raw %}

~~~html
<parent>
  <ng-template let-parentData1="data1" let-parentData2="data2">
    <!-- The "data1" and "data2" are available here -->
  </ng-template>
</parent>
~~~{% endraw %}

> In the above example, **data1** and **data2** are data from the Parent Component.

## ThemeProviderComponent

{% raw %}`ThemeProviderComponent`{% endraw %} is the root or parent component for other components.  
All components must be wrapped in this provider component to gain access to the theme object.  
It’s highly recommended to wrap your entire app at the highest level (see below):{% raw %}

~~~html
<theme-provider>
  <app>
    <layout>
      <grid>
        <div></div>
      </grid>
    </layout>
  </app>
</theme-provider>
~~~{% endraw %}

### ThemeProviderComponent snippet{% raw %}

~~~javascript
@Component({
  selector: "theme-provider",
  template: `
    <ng-container *ngIf="childAsTemplate">
      <ng-container *ngTemplateOutlet="template; context: theme"></ng-container>
    </ng-container>
    <ng-content *ngIf="!childAsTemplate"></ng-content>
  `
})
export class ThemeProviderComponent implements AfterContentInit {
  @ContentChild(TemplateRef, { static: false }) template!: TemplateRef<any>;
  theme: any = {
    palette,
    scales
  };
  childAsTemplate: boolean = false;

  constructor() {}

  ngAfterContentInit() {
    this.childAsTemplate = !!this.template;
  }
}
~~~{% endraw %}

### palette snippet{% raw %}

~~~javascript
const palette = {
  uiBlueDarker: "#071d40",
  uiBlueDark: "#0d3880",
  uiBlue: "#184da8",
  uiBlueLight: "#2765cf",
  uiBlueLighter: "#e60278",
  // ...
};
~~~{% endraw %}

### scales snippet{% raw %}

~~~javascript
const scales = {
  "spacing-01": "0.125rem",
  "spacing-02": "0.25rem",
  "spacing-03": "0.5rem",
  "spacing-04": "0.75rem",
  // ...
};
~~~{% endraw %}

> **palette** and **scales** are theme items provided for child components' usage.

## Usages

### Used in a Component

In this example, we create a button component that accepts {% raw %}`color` and `scale` as inputs and uses the theme object provided by `ThemeProviderComponent` for **palette** and **scales** values.

~~~javascript
@Component({
  selector: "my-button",
  template: `
    <button
      type="button"
      [style.color]="themeProvider?.theme?.palette[color]"
      [style.fontSize]="themeProvider?.theme?.scales['spacing-0' + scale]"
    >
      <ng-content></ng-content>
    </button>
  `
})
export class MyButtonComponent {
  @HostBinding("class") className;
  @Input() color!: string;
  @Input() scale!: number;

  constructor(
    @Inject(forwardRef(() => ThemeProviderComponent))
    private themeProvider: ThemeProviderComponent
  ) {}
}
~~~

> We get a reference to `ThemeProviderComponent` using `forwardRef`.  
> In the template markup, we utilize the theme for `palette` and `scale`.

Below is an example usage of the `my-button` component:

~~~html
<theme-provider>
  <my-button [color]="'uiBlue'" [scale]="9">
    Button
  </my-button>
</theme-provider>
~~~

### Used in ngTemplate

In this example, we customize the `my-button` component and gain access to the theme object through `ngTemplate`:

~~~html
<theme-provider>
  <ng-template let-palette="palette" let-scales="scales">
    <my-button>
      <div
        [style.color]="palette['uiYellow']"
        [style.backgroundColor]="palette['uiPink']"
        [style.fontSize]="scales['spacing-09']"
      >
        Button
      </div>
    </my-button>
  </ng-template>
</theme-provider>
~~~

## Summary

The theme provider lets us use the theme object (like **palette**, **spacing**, and **sizing**) in the scripting layer rather than the stylesheet layer.  
For those more comfortable styling components in JavaScript, this pattern can help speed up styling work.

You can get all the code used in this post here:  
👉 [https://stackblitz.com/edit/theme-provider](https://stackblitz.com/edit/theme-provider)

My first component in Angular - Box

Azizi Yazit — Wed, 07 Aug 2019 16:38:36 +0000

You can grab the code here https://stackblitz.com/edit/flexboxcssinjs

Box

All HTML elements can be considered as boxes. In CSS, the term "box model" is used when talking about design and layout.

The CSS box model is essentially a box that wraps around every HTML element. It consists of: margins, borders, padding, and the actual content. The image below illustrates the box model

In every design system that I made, Box component is the first component that I developed.

We uses Angular and emotionJS (CSS-in-JS) for code example.

Box component code (snippet version)

The Box component can be implemented as simple as this:

<Box p="20px 20px" ml="10px" mr="10px" w="200px" h="auto">
 Content
</Box>

Please note that we are not using brackets [rule]="value" as we are expecting literal string.

And we can extend the Box to create other component e.g Flexbox

By using Flexbox component, creating a flexbox is not an issue anymore

<Flexbox w="100vw" justifyContent="space-between">
  <Box w="50px" h="50px" bgColor="rebeccapurple">
  </Box>
  <Box w="50px" h="50px" bgColor="rebeccapurple">
  </Box>
  <Box w="50px" h="50px" bgColor="rebeccapurple">
  </Box>
</Flexbox>

We can also do a checking on the value and helps developer to identify the typo (me myself is not kind of person who remember all the rule values)

Here is an example how to add simple validation on values.

In above example we check the value of justifyContent and only if its a valid value, the justifyContent rule added into style.

Box component can be Base component to other components e.g. Semantic Components like section, header, article, nav and many more...

Semantic components

class SectionComponent extends BoxComponent {}

class HeaderComponent extends BoxComponent {}

class ArticleComponent extends BoxComponent {}

class NavComponent extends BoxComponent {}

Summary

Abstracting the Box component as a Base component will make our life easier because all the components of HTML can be considered as a boxes. Like Box component, all the HTML elements (boxes) is consists of:

Content The content of the box, where text and images appear
Padding Clears an area around the content. The padding is transparent
Border A border that goes around the padding and content
Margin Clears an area outside the border. The margin is transparent

By extending the Box component, all mentioned above have been covered.

Performance optimizations in React

Azizi Yazit — Tue, 06 Aug 2019 16:52:34 +0000

In computing, memoization is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again
~wikipedia

React used Virtual DOM to reduce browser reflow and repaint using diff algorithm called "Reconciliation". "Reconciliation" is fast but when we have too many of them (re-renders), its too costly and we should plan for optimization.

React have 2 built-in hooks to prevent unnecessary renders in component that rely on reference equality. And to avoid recompute expensive calculations. Those hooks is useMemo and useCallback.

Reference equality means that two object references refer to the same underlying object.

An experienced JavaScript developer know that below code is return false

{} === {} // false
[] === [] // false
() => {} === () => {} // false

Example of expensive calculation is checking for prime number

function isPrime (num) {
  if (num <= 1) {
    return true
  } else if (num <= 3) {
    return true
  } else if (num%2 === 0 || num%3 === 0) {
    return false
  }

  let i = 5
  while (i*i <= num) {
    if (num%i === 0 || num%(i+2) === 0) {
      return false
    }
    i += 6
  }
  return true
}

without memoization, I can't imagine that the function above run/triggered every render.

useMemo hook

useMemo will return a memoized version of the value (all types including function) that only changes if one of the dependencies has changed.

Here is example use-case of useMemo

the memoizedTasks only triggered a render when there is a changes in tasks state. You can see the console.log only triggered when tasks state changed.

Any changes to others state in statisticModuleContext will not causing re-render of TodoList.

useCallback hook

useCallback will return a memoized version of the callback that only changes if one of the dependencies has changed.

And both useMemo and useCallback can behave similarly:

useCallback(fn, deps) is equivalent to useMemo(() => fn, deps).

However, usually useCallback used for parent-child component.

parent-child component

When we have identified a parent component that have a high possibility to re-renders a lots, we can use useCallback to prevent unnecessary re-render of the child.

Consider below code examples (i took the example from Kent C Dodds article as to me its the most clear example)

DualCounter is the parent component that have CountButton as a children. When DualCounter is re-rendered, its functions (increment1 and increment2) will be renew/reinitiated and causing re-render of the CountButton. This is because the increment1 and increment2 is the child dependency.

By using useCallback and without function dependency changes, we be able to prevent the unnecessary re-render of the CountButton as the functions have been memoized.

Please aware that optimization comes with price and should only be used on a VALID use-cases as we mentioned above.

React is VERY fast and there are so many things I can think of for you to do with your time that would be better than optimizing things
~Kent C Dodds

React as State Management Library

Azizi Yazit — Tue, 30 Jul 2019 14:51:00 +0000

State

In the context of User Interface (UI), state is data that hold current information that influences the output of render. Its changed over time.

State is user define, so its not only related to component or UI control.

State management library

State management refers to managing the UI states. As applications grow, this can end up becoming one of the most complex problems in UI development.

State management library provide us ability to store the states and exposing an API for UI components across application to access, add and update the states. Example of state management libraries is React (this is not typo) and Redux.

Redux

Redux attempts to make state mutations predictable by imposing certain restrictions on how and when updates can happen. These restrictions are reflected in the three principles of Redux (Single source of truth, State is read-only and Changes are made with pure functions).

React as state management library

If you're building an application with React, you already have a state management library installed in your application. You don't even need to npm install (or yarn add) it. It costs no extra bytes for your users, it integrates with all React packages on npm, and it's already well documented by the React team. It's React itself.
~ Kent C. Dodds

The question now, did we need Redux?
You can find the answer in React doc

Choosing the right state management library is quiet a critical decision. To choose the best for your scenario require an understanding of the "states"

component state

State thats used in locally.

For example button component that uses its clicked state to show loader and icon (both loader and icon is sub component of button)

The button component can be illustrated here

Component state can be managed easily using useState hook.

module state

State thats used across different components in module scope that they (the components) are invoked.

For example listing module that have table component and pagination component. Table used pagination page selected state to changed its data display.

The listing module can be illustrated here

For managing module states, we can use Context API with useReducer

page state

State thats used across different modules in page scope.

For example login module and sign up module that can be toggled based on user interaction their buttons

The login/sign up module can be illustrated here

React have solid technique to manage state in page called lifting up state

So far we have no issues managing 3 types of states (component, module and page) using JUST React. Left is one more type of state, global state.

global state

User submit username and password (local state) in Login page, the loggedIn state (local state) used to show loader and redirect to Dashboard page with data like userId (global state?) passed along the way. userId used by menu module to get the user role and display menu item based on role provided.

Did the userId can be considered as global state?
No. Because it does not changed over time and it can be passed as prop.

Data like userId and others (same type) have been classified wrongly as global state.

You don’t need Redux if your data never changes. The whole point of it is managing changes.
~ Dan Abramov

When prop-drilling problem can be solved by using React (Context API), the only things I think useful to use Redux is managing global state. But when your application is composition of providers (modules) that have its own reducer managing the states on module scope, it seem we don't need global state. In other word, we don't need Redux anymore.

A lots of info, tips and solution that can be seen here. Peoples who involves in the discussion is the Kent C Dodds, Mark Erikson (Redux maintainer), Brian Lonsdorf and many other great React developers.

CLI in React

Azizi Yazit — Fri, 26 Jul 2019 15:02:28 +0000

Here’s your Markdown with proper formatting, fixed grammar, and cleaned-up section structure while preserving all content:

---
title: CLI in React
published: true
description: Learn how to use a CLI tool with React to create consistent app, page, module, and component structures.
tags: react, reactarchitecture, reactcli
---

## React and CLI

React has its own CLI, but currently, it only supports creating an app using **create-react-app**.  
`create-react-app` generates the boilerplate version of a React application via the command line.

```

bash
npx create-react-app my-app

Note: create-react-app takes care of setting up the main structure of the application as well as several developer settings. Most of what you see will not be visible to visitors of your web app.
React uses a tool called webpack, which transforms the directories and files here into static assets. Visitors to your site are served those static assets.
~ codecademy.com

Each React app that you or your team creates will have the same structure — which is great for consistency across applications.

However, UI development is not only about building apps; it also involves creating components, modules, and pages. Developers should know what needs to be built by referring to the wireframe provided by the designer.

Without a defined structure, you can end up with a messy and inconsistent application.

Example Scenarios

Dev 1

Dashboard page
Header component
Card component
Graph component

Dev 2

Dashboard page
Header module (container for search component, icons component, and dropdown component)
Statistic module (container for one variant of the card component)
Multi-variant Card compound component

Dev 3

Admin page

If three developers work on the same project without a standard structure, you may get three different approaches — yuck!

A CLI for generating boilerplates (components, modules, and pages) provides the benefit of a consistent structure.

1. Setup the CLI

We will use plopJS, a micro-generator framework for the command line.
PlopJS templates use the powerful Handlebars templating engine, which allows you to build semantic templates effectively.

Steps

Add plopJS into your package.json:


json
"devDependencies": {
  "plop": "^2.3.0"
}

Install the dependency:


bash
npm install

2. Define the Structure

Pages

A Page is a container for modules. It manages communication between modules inside it.
Read more about Pages.


jsx
<Page>
  <ModuleA />
  <ModuleB />
</Page>

Modules

A Module is a container for components. It manages communication between the components inside it.
Read more about Modules.


jsx
<Module>
  <ComponentA />
  <ComponentB />
</Module>

Components

A Component is a feature within a module.


jsx
<ComponentA>
  <section>
    <article>
      Article
    </article>
  </section>
</ComponentA>

3. Create a `plopfile.js` Configuration

Create plopfile.js in the same directory as package.json:


javascript
module.exports = function (plop) {
  plop.setGenerator('component', { ... });
  plop.setGenerator('module', { ... });
  plop.setGenerator('page', { ... });
};

For this tutorial, we will focus on creating a generator for a component.
You can find complete generators here.

Templates

Script file
Test file
Style file
Index file

Save all the templates inside a plop-templates folder.

4. Create a Generator

Here’s an example generator for a component:

Once everything is ready, let’s test the generator.

Add a new npm script named "cmd" that runs "npx plop".
If everything is set up correctly, you will see a list of generators to choose from.

Start answering the prompts, and once completed, your component will be generated:

Generated Files

Card.js
Card.style.js
Card.test.js
index.js

Summary

Using a CLI makes it easy to create apps, pages, modules, and components that follow the best practices and structure defined by you and your team.
By automating component generation, you save development time and ensure consistency, allowing developers to focus on building features.

📂 Full Source Code
https://github.com/abumuawiyah/react-boilerplate

Style Guide Driven Development

Azizi Yazit — Tue, 23 Jul 2019 15:44:57 +0000

"We are not designing pages, we are designing systems of components."
~ Stephen Hay

Style Guide Driven Development (SGDD)

SGDD is about converting static style guide into dynamic style guide from the earliest stages of User Interface (UI) development. The dynamic style guide also known as Living Style Guide.

Static Style Guide (SSG)

The static style guide is a file that documents typography, colors/palettes, fonts and many more. They also contain details like spacing info (margin and padding). Nowadays designer prefer to use more sketch-friendly tool like Zeplin.

Living Style Guide (LSG)

Living Style Guide reflects the latest version of the implemented design and includes demos showing interaction and behaviour. Example of the LSG is the extremely popular Bootstrap

All the components placed in the left panel and the right panel contain the view of the component and below it is the code to be used by Developers.

A design system isn't just a library of assets with some documentation, it's how you collaborate and communicate between teams and disciplines.
~ Nataly Athree at "cssday"

Before we go to Development life-cycles with SGDD, let's discuss methodology being used in component development. There is plenty of them and my personal choice is Atomic Design.

Atomic design is a mental model that allows you to concurrently create both the parts and the whole of a UI design system
~ Brad Frost

This methodology analyzes the relationships between the different parts of the system and how they interrelate, using chemistry as an analogy.
~ Adriana De La Cuadra (Bitovi)

Atoms

Atoms are the basic building blocks of matter. Applied to web interfaces, atoms are our HTML tags, such as a form label, an input or a button.

Molecules

Molecules are groups of atoms bonded together and are the smallest fundamental units of a compound.

Organisms

Organisms are groups of molecules joined together to form a relatively complex, distinct section of an interface.

Templates

Templates consist mostly of groups of organisms stitched together to form pages.

Pages

Pages are specific instances of templates.

SGDD with Atomic Design

1. Design Audit

This is when the designer gathered all the requirements and created SSG.
At this stage the LSG serves as a reference when creating designs. Designer would refer to LSG and considering to reusing or extending the atoms components or create the new atom component.

2. Component Abstractions

Once the designs are ready to be implemented, designers and developers can use the style guide to discuss how the new features should be broken down into separate components. These is where activity like recomposing the molecules and introducing new component variants happened.

3. Publish into Living Style-Guide

This is the process where the component development started. With SGDD in mind the development is all about creating the component and documenting it in LSG. In the end, the LSG becomes both a framework and a playground.

It's a framework because it provides the rules that define how elements should look and behave.
It's a playground as implementer or application developers can interact and straight away see how the component behaves.

4. Integration

Application developer (library implementor) uses the atoms and molecules components by referring to the LSG for code sample and implementation guide to come up with templates and pages. Its "plug and play" game.

You've heard of plug-and-play. This is plug, unplug and play. It's so simple to use, it's unbelievable. ~ Steve Jobs

LSG with Storybook

Storybook is the most popular UI component development tool for Angular, React and Vue. It helps you develop and design UI components outside your app in an isolated environment.
This article uses Angular as development tool for UI component.

Basic features of Storybook is Action, Story and Knobs

Action

Track any interaction to the component like "click", "mouseover", "double-click" and many more.

Story

Implementation code that can be copied by developer.

Knobs

Knobs allow us to edit the component inputs dynamically.

Storybook is a powerful frontend workshop environment tool that allows teams to design, build, and organize UI components (and even full screens!) without getting tripped up over business logic and plumbing ~ Brad Frost

Storybook has made developing components more streamlined by allowing us to easily include technical documentation within our design system! ~ Taurie Davis

Setting up the Storybook

Its recommended to use the official guide. If everything going smoothly, the command for creating angular-storybook is just one line command:

npx -p @storybook/cli sb init --type angular

Summary

One way to bridge the gap between developers and designers is to bring the SGDD into our workflow. Combining SGDD with Atomic Design helps to accelerate the process of creating modular designs. Having Living Style Guide as single truth documentation boosts development time and team communication.

CSS-in-JS for Angular

Azizi Yazit — Sun, 21 Jul 2019 16:46:50 +0000

Why CSS-in-JS?

Primarily, CSS-in-JS boosts my confidence. I can add, change and delete CSS without any unexpected consequences. My changes to the styling of a component will not affect anything else. If I delete a component, I delete its CSS too. No more append-only stylesheets!
~ Max Stoiber

I am highly recommended developer who have a plan to use CSS-in-JS to read Max Stoiber article. The points stated in the article is applicable for all frameworks (not only React).

Me and CSS-in-JS

To be honest, I am not great at CSS and facing a lots of challenges to design the architecture or organisation for my CSS's. How I survived in my works is by dividing the works into scripting and styling. I do most on the scripting and lets my colleagues in-charge on CSS/SaSS part.

"i found a light in the dark" when I heard about CSS modules. However I am struggling to integrate the tool with Angular environment and I give up with CSS modules.

When I moved to new company this year, the company stack is React and Styled-Components. This is when I really "found a light in the dark".

Styled-Components

styled-components allows you to write actual CSS code to style your components. It also removes the mapping between components and styles. However styled-components do not have a support for Angular. But don't worry, we can use other CSS-in-JS tool called emotionJS.

emotionJS

emotionJS is a library designed for writing css styles with JavaScript. It provides powerful and predictable style composition in addition to a great developer experience with features such as source maps, labels, and testing utilities. Both string and object styles are supported. emotionJS is framework agnostic.

adding emotionJS into our Angular project

no babel and no webpack config required, its just one single command

npm i emotion
~~~

and use it in JavaScript/TypeScript by import its core function <b>css</b>

~~~javascript
import { css } from "emotion"
~~~

here is sample emotionJS in vanilla JavaScript

![](https://thepracticaldev.s3.amazonaws.com/i/k7r0s1euiu4n19aruucw.png)

### emotionJS with Angular

>It is not until you rhyme with a person that makes you their perfect match, it is when you are satisfied with each others peculiarities, and find jewels in their loopholes.
~ Michael Bassey Johnson

CSS-in-JS is not popular in Angular community and this might be because Angular already have solid styling mechanism and shadow DOM encapsulated your styling to not affecting others while block from side-effects from outside. You can refer this article by [Ashnita Bali](https://ultimatecourses.com/blog/using-ngstyle-in-angular-for-dynamic-styling?fbclid=IwAR3nZH-_CSazBMOprkeXD7uUVtkNpusr0OU7CeJFPWjUzBurwlqDdQs4eJM). However for those who are more comfortable in JavaScript land might like to try styling alternative like CSS-in-JS. 

In this article, we will go thru step by step to applying style based on @Input properties

### step 1 - define component variants (@Input()) 

![](https://thepracticaldev.s3.amazonaws.com/i/njj0iphgd246uh7ntaji.png)

### step 2 - provide default value for all the variants

![](https://thepracticaldev.s3.amazonaws.com/i/o9aabvoznkthhfmrc3vt.png)

### step 3 - listen to the change of the variants and apply styling dynamically

![](https://thepracticaldev.s3.amazonaws.com/i/211jele5qvcerh8a87yr.png)

![](https://thepracticaldev.s3.amazonaws.com/i/okp1iownqu6vv3mlm0d4.png)

- getDynamicStyle method check the variant and assign the styling based on the state of the variant
- its easy to styling your component using component state

here is the [gist](https://gist.github.com/abumuawiyah/6ac9272fc3a5c95e21c915900846042f) for complete script.

Create Page in React

Azizi Yazit — Tue, 16 Jul 2019 08:32:22 +0000

Liquid syntax error: 'raw' tag was never closed

Create module in React

Azizi Yazit — Mon, 08 Jul 2019 15:27:49 +0000

There is no module been defined in React and its known that React give full control on the code structure to the developers.

module

module can be use to make the code structure better. In React, I like to create a module as a Provider. This is because provider is the one who supply the props, callbacks and data to its consumers (children).

module as provider

const ModuleAContext = createContext({})
const initialState = { stateA: '', stateB: false, stateC: {}}

function ModuleA (props) {
 const [providerState, dispatch] = useReducer(reducer, initialState)
 const moduleAContextValue = {...props, providerState, dispatch}

 function reducer (state, action) {
  switch (action.type) {
   case STATE_A_CHANGED: 
    return { ...state, stateA: action.stateA }
   case STATE_B_CHANGED: 
    return { ...state, stateB: action.stateB }
   case STATE_C_CHANGED: 
    return { ...state, stateB: action.stateC }
   default: 
    return initialState
  }
 }

 return (
  <ModuleAContext.Provider value={moduleAContextValue}>
   <ChildA />
   <ChildB />
   <ChildC />
  </ModuleAContext.Provider>
 )

}

As provider, moduleA is not only responsible for supplying the data and the callback but also manage events that happened in its children (dispatch).

create module children as a consumers

function ChildA () {
 const moduleAContext = useContext(ModuleAContext)

 function handleClick (a) {
  dispatch({type: STATE_A_CHANGED, stateA: a })
 }

 return (
  <div onClick={handleClick}>{moduleAContext.stateA}</div>
 )
}

function ChildB () {
 const moduleAContext = useContext(ModuleAContext)

 function handleClick (b) {
  dispatch({type: STATE_B_CHANGED, stateB: b })
 }

 return (
  <div onClick={handleClick}>{moduleAContext.stateB}</div>
 )
}

function ChildC () {
 const moduleAContext = useContext(ModuleAContext)

 function handleClick (c) {
  dispatch({type: STATE_C_CHANGED, stateC: c })
 }


 return (
  <div onClick={handleClick}>{moduleAContext.stateC}</div>
 )
}

The Consumers is a components that been used by the module. They communicate thru context of the module (ModuleAContext).

summary

We have using Context API and use provider-consumers pattern to expose the module props, module state and callbacks to its children (consumers). Adding module in code system helps developer to design complex component as mixture of component that's live under one module.

next series

We will talk about "Creating page in React" where page is Container that contains many modules. And we will use custom hooks for modules communication.

DEV Community: Azizi Yazit

From Scrum to Extreme Scrum: How to Supercharge Agile Teams

Introduction

Scrum:

Extreme Scrum (XS)

Daily Code Standup – Driving Continuous Integration

Key benefits of a Daily Code Standup:

Pair Programming vs. Team-Wide Pair Programming

Desk Checks

1. Desk Check with the Product Owner (PO) – Driving Early and Continuous Feedback

2. Desk Check with Tester / Automation Engineer – Driving Continuous Test Automation

Benefits:

Continuous Automation Testing

XS Test-First vs TDD: What’s the Difference?

XS Test-First Flow

Process Retrospective – Driving Objectivity and Continuous Improvement

Traditional Scrum Retrospective vs XS Process Retrospective

Example: A Day in Extreme Scrum (XS)

Key Takeaway

Higher Order Component enabled by Ivy

Higher Order Component - HOC

Angular HOC

Be creative

withAuth

withRouter

withProvider

Code repository

Angular theme provider

forwardRef

My first component in Angular - Box

Box

Box component code (snippet version)

Semantic components

Summary

Performance optimizations in React

useMemo hook

useCallback hook

parent-child component

React as State Management Library

State

State management library

Redux

React as state management library

component state

module state

page state

global state

CLI in React

Example Scenarios

1. Setup the CLI

Steps

2. Define the Structure

Pages

Modules

Components

3. Create a plopfile.js Configuration

Templates

4. Create a Generator

Generated Files

Summary

Style Guide Driven Development

Style Guide Driven Development (SGDD)

Static Style Guide (SSG)

Living Style Guide (LSG)

Atoms

Molecules

Organisms

Templates

Pages

SGDD with Atomic Design

1. Design Audit

2. Component Abstractions

3. Publish into Living Style-Guide

4. Integration

LSG with Storybook

Action

Story

Knobs

Setting up the Storybook

Summary

3. Create a `plopfile.js` Configuration