DEV Community: Federico Giacomini

Track your NGRX Actions State

Federico Giacomini — Tue, 28 Dec 2021 05:12:25 +0000

In this article, I would like to propose a solution for handling the state of multiple actions inside your Ngrx store. I will assume you already know the basics of Ngrx or other Redux pattern-based state management tools and are also pretty familiar with Angular and Typescript, as I will go pretty quick on the details.

One of the most common situations when using a reactive state management library is handling asynchronous API. The most common approach to tackling async operations is creating three actions for each possible outcome (request/success/failure) and making a side effect handling each of them. It is also common to have some flags in our state that track the store's current state.

Here is a classic example in NGRX very similar to the one in the "example repository" :

actions.ts

export const userAddRequest = createAction(
  '[User] User Add Request',
  props<{username: string}>()
);

export const userAddSuccess= createAction(
  '[User] User Add Success',
  props<{username: string, id: number}>()
)

export const userAddFailure = createAction(
  '[User] User Add Failure',
  props<{message: string}>()
)

effect.ts

  userAddRequest$ = createEffect(() =>
    this.actions$.pipe(
      ofType(userActions.userAddRequest ),
      exhaustMap(({username}) =>
        this.userService.add({username}).pipe(
          map(response => userActions.userAddSuccess(response)),
          catchError((error: any) => of(userActions.userAddFailure(error))))
      )
    )
  );

  userAddSuccess$ = createEffect(
    () =>
      this.actions$.pipe(
        ofType(userActions.userAddSuccess),
        tap(() => {
          alert('User Add Succeeded');
        })
      ),
    { dispatch: false }
  );

  userAddFailure$ = createEffect(
    () =>
      this.actions$.pipe(
        ofType(userActions.userAddFailure),
        tap(() => {
          alert('User Add Failed');
        })
      ),
    { dispatch: false }
  );

reducer.ts

export interface State {
  users: User[];
  isLoading: boolean;
  isLoadingSuccess: boolean;
  isLoadingFailure: boolean;
}

const reducer = createReducer(
  initialState,
  on(userActions.userAddRequest, (state) => ({isLoading: true})),
  on(userActions.userAddSuccess, (state, {user}) => ({users: state.users.concat(user) , isLoading: false, isLoadingSuccess: true})),
  on(userActions.userAddFailure, (state, {user}) => ({user, isLoading: false, isLoadingFailure: true})),
);

selector.ts

export const getLoaded = (state: State) => state.isLoadingSuccess;
export const getLoading = (state: State) => state.isLoading;

This works nicely in many scenarios, but I found this approach to be fairly limited when we would like to give more advanced feedbacks to users.

Let's imagine the following UI :

We have a list of users on the left and a form to create a user on the right. This page effectuates three operations on our User Store :

getUsers
deleteUser
createUser

Out of those three operations, we would like to display a specific loader on the page :

When users are being loaded, we would like to show a loader on the list.
When a user is being deleted, we would like to show
a loader ONLY on the user that is being deleted.
When a user is being created, we would like to show
a loader on the Create Button.

A single flag would not work correctly since all those operations are contained in the same store module. We would have to set a flag for each operation inside the store or add some variable in our component to hold which process is currently executed.

But this is troublesome and would add a lot of logic; what if we could track the state of each Action independently?

Tracking The State of any NGRx Action

To make things easier, we can create a unique loader store in our application that we use for the single purpose of tracking actions and their state. It allows us to track the current state of any dispatched Ngrx action that we wish to follow.

First, we replaced the booleans flags with a simple enum instead. It is quicker to change a single property and less prone to situations where a flag is forgotten in a wrong state like {isLoading: true, isSucceded: true}:

export enum ActionState {
  LOADING = 'LOADING',
  SUCCEEDED = 'SUCCEEDED',
  FAILED = 'FAILED',
}

From here, the idea is to consider "async" actions as a single set. Each Action in a set would share a key with others, and we would use it to update the state of that operation in our loaders store.

One way to do this is to create a wrapper over our Actions using createAction with method. It will allow us to add some metadata alongside the Action definition. This metadata can be anything.

export const userAddSetkey = '[User] User Add Key';
export const userAddRequest = createAction(
  '[User] User Add Request',
  function prepare(payload: {username: string, password: string}) {
    return withLoader({ [userAddSetkey]: ActionState.LOADING }, payload);
  }
);
export const userAddSuccess = createAction(
  '[User] User Add Success',
  function prepare() {
    return withLoader({ [userAddSetkey]: ActionState.SUCCEEDED }, null);
  }
);
export const userAddFailure = createAction(
  '[User] User Add Failure',
  function prepare(payload: { message: string }) {
    return withLoader({ [userAddSetkey]: ActionState.FAILED }, payload);
  }
);

You can assign an anonymous function; we went with prepare because it is more similar to the redux prepare. This function adds additional information to the payload and the actions when they are initialized.

As you may note, we also wrote a simple wrapper withLoader around our payload. This method will add a property key that will be the same for each Action in our application that implements the tracking. That property will be helpful to know if the dispatched Action contained a state tracker or not.

export const LOADER_KEY = '@ngrx-custom-loader';

export type WithLoader<T> = T & {
  [LOADER_KEY]: { [k: string]: ActionState };
};

export function withLoader<T>(loader: Partial<{ [k: string]: ActionState }>, payload?: T) {
  return Object.assign(payload || {}, { [LOADER_KEY]: loader }) as WithLoader<T>;
}

When creating Action using withLoader, we will access a new property alongside type and payload that will store the action key and the state. We define this new Action structure as WithLoader<T>.

if you now log an action that implements the above structure, it will result like the following :

    {
        @ngrx-custom-loader: {'[User] User Add Key': 'LOADING'}
        type: "[User] User Add Request"
        payload: {username: 'jhon'}
    }

Finally, we need to make some use of those loader keys. We implemented a loader store that will save the state of all actions implementing withLoader.

state.ts

export interface State {
  actionState: Record<string, ActionState>;
}

export interface LoadersPartialState {
  readonly [LOADERS_FEATURE_KEY]: State;
}

export const initialState: State = {
  actionState: {},
};

It starts empty {} and will grow every time an action is dispatched to look something like this.

{
    '[Login] Login Key': 'SUCCEEDED',
    '[User] User Add Request': 'LOADING',
    ...
}

Our reducer will check if the current Action contains our custom property LOADER_KEY assigned above. If yes, we will store this action state; else, it will do nothing.

reducer.ts

export function reducer(
  state: State | undefined = initialState,
  action: Action | WithLoader<Action>
) {
  if (Object.prototype.hasOwnProperty.call(action, LOADER_KEY)) {
    const loader = (action as WithLoader<Action>)[LOADER_KEY];
    return {
      ...state,
      actionState: {
        ...state.actionState,
        ...loader,
      },
    };
  }
  return state;
}

And last, the selector will check the store content and return the state of a specific action. We can pass an array of Actions that we would like to know the state, and it will return a boolean if any of them is currently loading. You can implement the same for Failure, Success, etc., or just one that would give back the state.

selector.ts

export const getIsLoading = (actions: string[] = []) =>
  createSelector(getLoadersState, (state) => {
    if (actions.length === 1) {
      return state.actionState[actions[0]] === ActionState.LOADING;
    }
    return actions.some((action) => {
      return state.actionState[action] === ActionState.LOADING;
    });
});

// We added an additional state INIT used when the operation has never been called. 
export const getLoadingState = (action: string) =>
  createSelector(
    getLoadersState,
    (state) => state.actionState?.[action] || ActionState.INIT;
  );

Let's use our tracking system :

We can now quickly implement our previous UI requirement :

assuming you create all Actions correctly, we can do

    // The user are getting loaded
    this.store.dispatch(loadUsersList());
    this.usersLoading$ = this.store.pipe(
      select(getIsLoading([userListLoadSetKey]))
    );

    // A user is being delete
    // for this case you also need to store what user it getting deleted to show the feedback on the correct row.
    InDeletionUserId = userId;
    this.store.dispatch(deleteUser({ id: userId }));
    this.userDeleting$ = this.store.pipe(
      select(getIsLoading([userDeleteSetKey]))
    );

    // A user is being created
    this.store.dispatch(createUser({ id: accountId }));
    this.userCreating$ = this.store.pipe(
      select(getIsLoading([userAddSetKey]))
    );

    // Any of the above is loading
    this.isUserStoreLoading$ = this.store.pipe(
      select(
        getIsLoading([userListLoadSetKey, userDeleteSetKey, userAddSetKey])
      )
    );

By using getLoadingState, you can also track when an operation is finished; helpful in those rare cases where you would like to execute a side effect to Actions outside of an NGRx effect. For example, reset a form when a user is created :


  onSubmit() {
    this.form.controls.username.disable();
    this.store.dispatch(userAddRequest({ ...this.form.getRawValue() }));

    this.store
      .pipe(select(getLoadingState([userAddSetKey])))
      .pipe(
        takeWhile(
          (state) =>
            ![ActionState.SUCCEEDED, ActionState.FAILED].includes(state),
          true
        ),
        filter((state) => state === ActionState.SUCCEEDED),
        tap(() => this.form.controls.username.enable())
      )
      .subscribe();
  }

You can find a demo of this approach on the following Stackblitz or Repository.

I hope I didn't go too fast and that this post was helpful. It works very fine on our project, but we might have overlooked some behaviors. One central flaw point that I didn't cover is clearing the loaders once in a while (on route navigation, for example) to avoid storing gigantic objects in your NGRx store. But this is only problematic if your project contains a lot of Action, and we currently only have 150 actions. Please feel free to comment and give feedback on such an approach. Also, do not hesitate to ask for clarification or points I passed over too quickly.

Thank you, and see you in the next post!

Share Components across Front Ends frameworks using Nx and Web Components - Part 3

Federico Giacomini — Sat, 13 Nov 2021 03:19:00 +0000

This is the third of a three parts Guides:

Part 3 - Output Event and Allow Retrocompatibility

In part one, we introduced Web Components, what they are and how to use them. We also created and set up an Nx workspace with an Angular and React project alongside a shared Web Components library. We created a custom element that "listens" to the attribute title and changed the DOM content accordingly. The second part added some custom styles and showed how to pass complex objects via attribute and property.
This final section will focus on Events and listening to them in our app and Polyfill to allow our web component to work on old browsers.

1. Dispatch and receive Events

If you follow the previous three parts, you should already have your monorepo setup with your shared library and the Angular and React app ready. We are going to create a new shared Web Component to showcase events. A simple counter that increments on button click and dispatches an event with the current value outside of the component.

let's start with the template, nothing new here :

const template = document.createElement('template');
template.innerHTML = `<style>
    #count {
      color: red;
    }
  </style>
  <p>button clicked <span id="count">0</span> times</p>
  <button id="btCounter">Click Here</button>`;

Let's create the component code, a counter with an optional initial value, which will increment according to each button click. There is nothing new here :

export class DemoCounterElement extends HTMLElement {
  private _count = 0;
  get count(): number {
    return this._count;
  }

  set count(val: number) {
    this._count = val
    this.update(this._count);
  }

  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.appendChild(template.content.cloneNode(true));
    this.shadowRoot.getElementById('btCounter').onclick = () => this.increment();
  }

  increment() {
    this.update(++this.count);
  }

  update(count: number) {
    this.shadowRoot.getElementById('count').innerHTML = count.toString();
  }
}

customElements.define('demo-counter', DemoCounterElement);

Export this component from your library (remember it's the index.ts) and import it in Angular and react :

In our Angular component template (we start counting from 1):

<demo-counter [count]="3"></demo-counter>

And in our React component (we start counting from 2):

export function App() {
  const counter = useRef<DemoCounterElement>(null);

  useEffect(function () {
    if(counter.current) {
      counter.current.count = 2;
    }
  }, []);

  return (
    <div className={styles.app}>
      <demo-counter ref={counter} />
    </div>
  );
}

export default App;

If you start both apps, it will already increment the counter on each click, but we would like to get notified outside of our Web Components when users click the button. To do this, we will need to dispatch a Custom Event from our Web Component and listen to it in our apps. Custom Event is an interface representing events initialized by an application for any purpose.

In our Web Component increment method, let's create and dispatch a new custom Event.

  increment() {
    this.update(++this.count);
    this.dispatchEvent(new CustomEvent<{ count: number }>('incremented', {detail: { count: this.count }}));
  }

We use detail to pass any data we would like to share from this event. detail will be readonly once the event is initialized.

With this simple change, let's update our Angular and React to log the event in the console.

In Angular template, we can now bind the event :

<demo-counter [count]="3" (incremented)="clicked($event)"></demo-counter>

and in the component code :

  clicked(event: Event) {
    console.log(event)
  }

For React, things are not as simple. Our event is not a native one, and there is currently no simple way (as far as I know) to listen to that event directly from the template. You will either need an additional library like xeact or use the ref as we did for the properties. There are several issues in the React repository asking for easier management of custom events, but none have been implemented yet.

So we will use the useRef hook and the useEffect to add and remove our listeners.

export function App() {
  let eventRef: DemoCounterElement;
  const counter = useRef<DemoCounterElement>(null);

  const onIncrement = (e) => {
    console.log(e)
  }

  useEffect(() => {
    const counterRef = counter.current; 
    if(counterRef) {
      counterRef.count = 2
      counterRef.addEventListener('incremented', onIncrement)
    }
    return () => {
      if(counterRef) {
        counterRef.removeEventListener('incremented', onIncrement)
      }
    }
  })


  return (
    <div className={styles.app}>
      <demo-counter ref={counter}/>
    </div>
  );
}

Fire your app up again and check your console. Your log should appear in your React app.

Great, now you can pass attributes, properties and dispatch custom events from your Web Components! One last thing is left for us, adding Polyfill to make them compatibles with old browsers.

2 Add Polyfill

To ensure compatibility with older browsers, it is necessary to include a Web Components polyfills. Now, this is not a requirement, and it is OK only to target new browsers. The choice is up to you and your needs. As Angular says, "polyfills cannot magically transform an old, slow browser into a modern, fast one.", and the latest Angular 13 recently dropped support for IE11.

If you wish to allow an old browser to use your app, you will need to set up some polyfill to add additional code to the page and not break modern features that were not available before. Angular and React do not come with a specific polyfill for web components; we will have to add one manually. Luckily, there is a pretty popular repository that will do everything for us.

In your project, install @webcomponents/webcomponentsjs

npm install --save @webcomponents/webcomponentsjs

We now must load our Polyfill in Angular and React. For this feature, both frameworks work similarly.

Angular and React come with a file named polyfill.ts, which you will find in both projects src folders. We can add our Polyfill inside the file directly, and it will be loaded on pre es5 browsers.

Be sure to use the correct path.

polyfill.ts

 import "@webcomponents/webcomponentsjs/custom-elements-es5-adapter.js"
 import "@webcomponents/webcomponentsjs/webcomponents-loader.js"

You should be ready to go. You will need an old machine or a VM to test this or some testing service like lambdatest.

3 Conclusion

That is it for this series. You can now create your fully customized HTML elements and use them across various projects. While Web Components are not replacing current frameworks, they can be a great tool to complete them for things like shared UI library. I hope you learned something and that you enjoyed my firsts ever blog post series.
Thank You!

You can find the entire repo here :

https://github.com/Crocsx

Found a Typo or some problem?

If you’ve found a typo, a sentence that could be improved, or anything else that should be updated on this blog post, you can access it through a git repository and make a pull request. Please go directly to https://github.com/Crocsx/dev.to and open a new pull request with your changes.

Share Components across Front Ends frameworks using Nx and Web Components Part 2

Federico Giacomini — Thu, 28 Oct 2021 06:22:52 +0000

This is the second of three Part Guides:

Part 2 - Add Custom Style and Property Binding

In part one, we introduced Web Components, what they are and how to use them. We also created and set up an Nx workspace with an Angular and React project alongside a shared Web Components library. We created a custom element that "listens" to the attribute title and changed the DOM content accordingly. In this second part, we are going further by styling and assigning properties to our Web Components.

1. Style our Web Component

Our Web Component works, but they are very flat at the moment. It would be great to add some CSS to it. You may want to add a CSS class to our title and create a global stylesheet with some rules, and it would work. But the idea behind Web Components is creating fully independent elements that are auto-sufficient and do not require anything from the "outside". Adding a global CSS class would affect every element on our page and quickly turn into a gigantic file full of rules.

Hopefully, Web Components allow us to use Shadow DOM, which makes us able to keep the markup structure, style, and behavior hidden and separate from other code on the page. Thanks to it, elements will not clash, and the code will be kept simple and clean.

Let's head back to our library (set up in part one) and edit our title component (or create a new title element).

If you still have what we worked on, it should look like this (I removed the logs) :

export class DemoTitleElement extends HTMLElement {
    public static observedAttributes = ['title'];

    attributeChangedCallback(name: string, old: string, value: string) {
      this.innerHTML = `<h1>Welcome From ${this.title}!</h1>`;
    }
}

customElements.define('demo-title', DemoTitleElement);

In the above example, we just replaced the entire HTML inside our element for every update on our attribute title:

    attributeChangedCallback(name: string, old: string, value: string) {
      this.innerHTML = `<h1>Welcome From ${this.title}!</h1>`;
    }

As you may know, this method doesn't allow us to append some <style> tag. Therefore, we are unable to create new styles unless we manually write a class and add some global rules. Also, this approach is pretty poor in performance, as we recreate all the content for every change of our attribute. It would be great to have some kind of template...

Well, it turns out there is template element that would suit our need! Templates are not rendered in the DOM, but can still be referenced via Javascript. We can then clone this template inside our Shadow DOM once and access it across our components.

Let's create one outside of our component class and assign the styles we like.

const template = document.createElement('template');
template.innerHTML = `<style>
    h1 {
      color: red;
    }
  </style>
  <h1>Welcome From <span id="title"></span>!</h1>`;

You will notice I added a span with an id where we would like to write the dynamic title. It will come in handy for updating our DOM without having to recreate the template entirely.

Now in our Component constructor, attach a Shadow DOM, and append our template to it.

export class DemoTitleColoredElement extends HTMLElement {
    public static observedAttributes = ['title'];

    constructor() {
      super();
      this.attachShadow({ mode: 'open' });
      this.shadowRoot.appendChild(template.content.cloneNode(true));
    }
}

Here is what we added

super will call the constructor of HTMLElement
attachShadowattaches a shadow DOM tree to the specified element and returns a reference to its ShadowRoot. There can be two different encapsulation modes. open means elements of the shadow root are accessible from JavaScript outside the root while closed Denies access to the node(s) of a closed shadow root from JavaScript outside
this.shadowRoot.appendChild we are adding our template to the shadow Root and using template.content.cloneNode(true) we are cloning all the DOM element we defined in the template.

Now, this is much better; our template is cloned once and will be available through shadowRoot inside the component.

When the attribute change, we can now update what interests us inside the template. As we only care about the title attribute, we can simply add the following.

    attributeChangedCallback() {
      this.shadowRoot.getElementById('title').innerHTML = this.title;
    }

We should end up with a component similar to this :

const template = document.createElement('template');
template.innerHTML = `<style>
    h1 {
      color: red;
    }
  </style>
  <h1>Welcome From <span id="title"></span>!</h1>`;

export class DemoTitleColoredElement extends HTMLElement {
    public static observedAttributes = ['title'];

    constructor() {
      super();
      this.attachShadow({ mode: 'open' });
      this.shadowRoot.appendChild(template.content.cloneNode(true));
    }

    attributeChangedCallback() {
      this.shadowRoot.getElementById('title').innerHTML = this.title;
    }
}

customElements.define('demo-title-colored', DemoTitleColoredElement);

Nice! Remember to add this new element to your library's export and try it on your Angular and/or React project. I added the old title we created previously and the new one on the bottom. What we expect to see is our old title to remain Black, while our new title should be Red (and do not affect h1 outside of it)

<demo-title [title]="'Angular'"></demo-title>
<demo-title-colored [title]="'Angular'"></demo-title-colored>

AWESOME! Our style is applied only to our Component!

2. Passing object to Web Components

One common thing we would like to do is pass objects to our Web Component, and not just simple strings.

Since Web Component attributeChangedCallback and observedAttributes works exclusively with attribute, a possible solution would be to stringify objects and pass them via the attribute data-* and our HTML would remain valid.

Let's try this first, we are going to pass a person object to our Web Component and simply display that person's name.

2.1 Passing objects via attributes

In our library, create a new element that will observe a custom attribute named data-person

export class DemoObjectElement extends HTMLElement {
    public static observedAttributes = ['data-person'];

    attributeChangedCallback(name: string, old: string, value: string) {
      console.log(`Attribute ${name} value:`, value);
    }
}

customElements.define('demo-object', DemoObjectElement);

Add this new element to your library's exports, and let's first use it in Angular.

Inside app.component.ts create this object :

  person = {
    firstName: 'Jack',
    lastName: 'Doe'
  }

Move to the app.component.html add and assign our object to our web component. You have to specify Angular to use attribute by prefixing our binding with attr.person

<demo-object [attr.data-person]="person"></demo-object>

You will see that our Web Component log will look like this :

Attribute data-person value: [object Object]

Which is not what we want... To receive the entire object, we will need to use JSON.stringify first and then JSON.parse...

Update our Angular app.component.ts with the following line :

JSON = JSON;

and the template

<demo-object [data-person]="JSON.stringify(person)"></demo-object>

You can also update our Web Component log to display the value as an object

console.log(`Attribute ${name} value:`, JSON.parse(value));

It will now display our object as expected :

Attribute data-person value: {"firstName":"Jack","lastName":"Doe"}

For React, it is very similar. Open app.tsx and just add the following :

  return (
    <div className={styles.app}>
      <demo-object dataPerson={JSON.stringify(person)}/>/>
    </div>
  );

Since our Web Components are "natives" HTML elements, just assigning dataPerson will change the attribute data-person.

Passing objects as attributes is enough in some cases where we just want to assign small objects. But ideally, we do not wish to pollute attributes, and worst, assign objects that will need to be stringified and parsed at every change. What about passing things as properties instead? Well, we can, but it is a bit harder.

2.2 Passing Object via Properties

To allow our Web Component to receive properties, we first need to change a few things in the code. Web Components lifecycle works with attributes so we are required to manually detect property changes, and call our method ourselves. Additionally, as stated in the last part, Web Components are consumed like basic HTML, therefor passing property to HTML elements varies depending on the framework we use.

While we are at changes, let's also display the person's name and not just log it. Create a template in our component to do so.

const template = document.createElement('template');
template.innerHTML = `
<style>
    .name {
        font-weight: bold;
    }
</style>
<p>
    <span class="name">first name</span>
    <span id="firstName"></span>
</p>
<p>
    <span class="name">last name</span>
    <span id="lastName"></span>
</p>`;

Let's now change our component code. Assuming I would like to pass a property named person to my Web Component. If we do all like we are used to doing until now, we would be doing the following.

export class DemoProfileElement extends HTMLElement {
    public static observedAttributes = ['person'];

    constructor() {
      super();
      this.attachShadow({ mode: 'open' });
      this.shadowRoot.appendChild(template.content.cloneNode(true));
    }

    attributeChangedCallback() {
      this.update(this.person);
    }

    update(person: {firstName: string, lastName: string}) {
      this.shadowRoot.getElementById('firstName').innerHTML = person.firstName;
      this.shadowRoot.getElementById('lastName').innerHTML = person.lastName;
    }
  }

  customElements.define('demo-profile', DemoProfileElement);

But as your Typescript might tell, person is not an HTML attribute, so this.person is not defined. Additionally, the attributeChangedCallback will never be called since observedAttributes = ['person']; can't observe attributes that do not exist.

To fix this and make it work, we need to forget about what we did until now and implement our way to detect changes, like if we were coding a simple Typescript Class. You can try to fix it by yourself or just scroll for the solution.

We going to need a property in our class I chose _person, and a get/set that will assign to that property

export class DemoProfileElement extends HTMLElement {
    _person = {
      firstName: '',
      lastName: '',
  };

  get person(){
    return this._person
  }
  set person(value: {firstName: string, lastName: string}){
    this._person = value;
    this.update(this._person);
  }

  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.appendChild(template.content.cloneNode(true));
  }

    update(person: {firstName: string, lastName: string}) {
      this.shadowRoot.getElementById('firstName').innerHTML = person.firstName;
      this.shadowRoot.getElementById('lastName').innerHTML = person.lastName;
    }
}

customElements.define('demo-profile', DemoProfileElement);

Yes, we just use a get/set to check when the property is updated and update our DOM accordingly.

Let's try this in Angular, but before, don't forget to add this new element to your library's export!

When passing Input to a component, Angular will assign it as a property of that element. It makes things simple for us, as we do not need to change much.

In your Angular app, just add this line :

<demo-profile [person]="person"></demo-profile>

And that's it!

Let's head to React, where things are a bit different. React pass props as JSX Attributes, and therefore, simply doing <demo-profile person={person} /> will not work. We need to treat our Web Component as what it is, an HTML Element. So, get the reference and assign to it the property.

In your React app, add a Reference to our component, and after initialization, assigns the person property to our Web Component :

import { DemoCounterElement, DemoProfileElement } from '@demo-shared/demo-library';

export function App() {
  const person = {
    firstName: 'Jack',
    lastName: 'Doe'
  }
  const profile = useRef<DemoProfileElement>(null);

  useEffect(function () {
    if(profile.current) {
      profile.current.person = person 
    }
  }, []);

  return (
    <div className={styles.app}>
      <demo-profile ref={counter}/>
    </div>
  );

This is all also for React; start the project, and you will see the same result!

Great, we did almost all we would like to do, but there are still some things we might want to add.
In the last part, we will add some custom events to be dispatched in our Web Component and add polyfill to use our component on old browsers.

You can find the entire repo here :

https://github.com/Crocsx

Found a Typo or some problem?

Share Components across Front Ends frameworks using Nx and Web Components - Part 1

Federico Giacomini — Fri, 22 Oct 2021 05:57:08 +0000

This is the first of a three parts Guides:

Part 1 - Project Setup and Introduction to Web Component

Today we are going to discover a way to share components across React and Angular projects using Nx and Web Components. We are going to set up a simple Monorepo project using NX, and utilize web components to share some simple UI elements across Angular and React. If you do not know about Nx and Monorepos, follow this introductive blog post :
Introduction to NX and Monorepos.

### 1. What are web components?

As developers, we all know that reusing code as much as possible is a good idea. But this has traditionally been hard for markup language like HTML, where repetition is often complicated to avoid. Nowadays, popular frameworks like React and Angular became a standard because they allow the reusability of templates and logic. Web Components aims to solve such problems and make it possible to develop framework-agnostic, custom components that use the HTML syntax. Modern browsers can natively interpret them without any third-party library.

Now, this sounds great, why are we using React at all then? Well, Frameworks bring a lot more to the table than simple Web Components.
State machines, routing, retro compatibility, etc... But Web Components can still be useful in some cases. Let's suppose we have a few applications in our company using different frameworks, that we would like to share some UI elements. Well, it would be nice to make a library of those elements that would work the same way independently of the framework used. Web Components can be a good choice for this.

There is a lot of documentation about Web Components and I invite you to read some more in-depth posts about it : A Complete Introduction to Web Components in 2021

2. Create Our Workspace

We are going to start by creating an Nx Monorepo, with two projects inside (one in Angular and one in React), and a library (using the Custom Element API).

First, let's create an empty Nx workspace :

npx --ignore-existing create-nx-workspace demo-shared --preset=empty

Followed by an Angular and a React application, that you can name the way you want :

npm i -D @nrwl/angular
npx nx g @nrwl/angular:app demo-angular

We install the angular "extension" for Nx, then create a project.

npm i -D @nrwl/react
npx nx g @nrwl/react:app demo-react

Same here for react

You will now see in your apps folder 4 new applications, the Angular + Angular e2e and React + React e2e.
Great!

We are ready to add the library where we will add our shared components, and use them athwart Angular and React.

npx nx g @nrwl/workspace:lib demo-library

Ok, our workspace should be set up, and if you did it all correctly, your work tree should look something like this :

demo-shared/
├── apps/
│   ├── demo-angular/
│   ├── demo-angular-e2e/
│   ├── demo-react/
│   └── demo-react-e2e/
├── libs/
│   └── demo-library
│       ├── src/
│       │   ├── lib/
│       │   └── index.ts
│       ├── jest.conf.js
│       ├── tsconfig.lib.json
│       ├── tsconfig.json
│       ├── tsconfig.spec.json
│       └── tslint.json
├── README.md
├── angular.json
├── nx.json
├── package.json
├── tools/
├── tsconfig.base.json
└── tslint.json

Looking good? Great! Let's go to the next step, and start coding our shared component.

3. Shared Component using Web Components

You are now ready to do some basic Web Components. Our opening example will be a simple component that displays a title using an attribute and will change based on its value.

Add a new folder and file inside the lib folder :

demo-title/demo-title.element.ts

And let's add some example code

export class DemoTitleElement extends HTMLElement {
  public static observedAttributes = ['title'];

  connectedCallback() {
    console.log('Appended and connected to document')
  }

  disconnectedCallback() {
    console.log('Disconnected from document')
  }

  attributeChangedCallback(name: string, old: string, value: string) {
    console.log(`Element's attribute ${name} was ${old} and is now ${value}`);
    this.innerHTML = `<h1>Welcome From ${this.title}!</h1>`;
  }
}

customElements.define('demo-title', DemoTitleElement);

Quite a few things are available in the Web Components Lifecycle Methods :

observedAttributes: Define the name of the attributes that we will be able to bind as Input in React/Angular and receive updates in our Web Component Lifecycle method. In the above case, title is a property that can be assigned when creating the component.
connectedCallback: Invoked each time the custom element is appended and connected to the document's DOM.
disconnectedCallback: Invoked each time the custom element is disconnected to the document's DOM.
attributeChangedCallback Invoked each time that one of the observedAttributes is changed.
customElements.define('demo-title', DemoTitleElement); Defines a new custom element, mapping the given name to the given constructor as an autonomous custom element.

It is very important to note that Web Component attributeChangedCallback works with attributes and NOT with properties. To keep your HTML page valid, you should only use valid HTML attributes. Attributes are also required to be plain strings, so objects will require to be JSON.stringify first.
If you would like to pass custom attributes, you should use the HTML markup [data-*](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*) and bind anything you want to it.
In the second part of this post, we will discover a way to use properties instead, and bind any type of data.

Ok, Before being able to use our Web Component, we must NOT forget to add this element to our library's exports. Otherwise, we will not be able to import it, and we will break Nx cache and affected commands (the useful Nx command that will build only modified projects and dependencies each time a file is changed)

In your library folder, go to index.ts and add the export line :

export * from './lib/demo-title/demo-title.element';

Now that our component is available outside of our library. Let's connect it with Angular and React, starting with Angular.

4. Setup Angular and React for Web Component

4.1 Setup Angular to use Web Component

Inside your angular app, import the library, You can do it inside the main.ts

import '@demo-shared/demo-library'; // <-- our library

import { enableProdMode } from '@angular/core';

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app/app.module';

import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

platformBrowserDynamic()
  .bootstrapModule(AppModule)
  .catch((err) => console.error(err));

we also need to register CUSTOM_ELEMENTS_SCHEMA in our app module

import { CUSTOM_ELEMENTS_SCHEMA, NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule],
  providers: [],
  schemas: [CUSTOM_ELEMENTS_SCHEMA],
  bootstrap: [AppComponent],
})
export class AppModule {}

this will tell the Angular compiler to refrain from throwing errors when seeing non-standard element tags in our templates.

Finally, let's add the component to our app. Head to app.component.html and just add our title component as if it was a normal Angular component. Remember, the component name is the one you chose previously inside the method customElements.define

app.component.html should be as simple as this after you removed the boilerplate HTML autogenerated by Nx:

<demo-title [title]="'Angular'"></demo-title>

Start the app :

npx nx serve {angular app name}

and if all has been done correctly, you should see your component appearing with the Attribute you set!

4.2 Setup React to use Web Component

Let's do the same with React :

Inside main.tsx let's again import our library :

import '@demo-shared/demo-library'; // <-- our library

import { StrictMode } from 'react';
import * as ReactDOM from 'react-dom';

import App from './app/app';

ReactDOM.render(
  <StrictMode>
    <App />
  </StrictMode>,
  document.getElementById('root')
);

Also, same as in Angular, we need to tell React to allow components that are not defined within it. To allow this, we will need to create a type file on the root of the src folder or the React project. Name it intrinsic.d.ts and add inside the following :

declare namespace JSX {
  interface IntrinsicElements {
    [elemName: string]: any;
  }
}

Let's add our component in React :

export function App() {
  return (
    <div className={styles.app}>
      <demo-title title={"React"} />
    </div>
  );
}

export default App;

Run the React App, and you will see the same component but this time in React!

/!\ If you have a warning about the webpack version, and your react app does not start, you can opt into webpack 5 npx nx g @nrwl/web:webpack5 and then serve the app again
more Webpack 5 Migration

5. Conclusion

In this first part, we made a very simple Web Component and used it across our two different projects. There are many things to do with Web Components, you may have noticed that we only used extends HTMLElement. But Web Components can extend and customize any HTML element. You could for example create your customized HTMLVideoElements and use it in all the projects you want, even the ones in pure HTML/Javascript. Compatibility is still not perfect, But we will see how we can add polyfill to use our component on old browsers. Let's head to Part 2 where we going to customize our components and pass value using properties instead.

You can find the full repo here :

https://github.com/Crocsx

Found a Typo or some problem?

Introduction to Nx and Monorepos

Federico Giacomini — Fri, 01 Oct 2021 01:16:16 +0000

Welcome to my blog post; this is Giacomini Federico. I work as a Front-end Developer for the AnyLogi team. Today I would like to introduce you to Nx, a “Smart, Extensible Build Framework” for building your Web Applications.

This post will go through the following points:

A Quick introduction to Nx and Monorepos
Why did we choose Nx for AnyLogi
Create a simple Nx Monorepo
Conclusion

1. A Quick introduction to Nx and Monorepos

Nx is a framework that allows you to architect, test, and build your project at any scale with the most popular modern Front-end frameworks like React and Angular and Back-end ones like NestJs or Express. To make this possible, Nx comes shipped with a large toolset that simplifies your Monorepo management. If you are unfamiliar with Monorepo, it is basically a version-controlled code repository that holds many projects and libraries. The Monorepo approach has several benefits over a common one. Here are a few:

Shared code - It is already possible with properly fragmented repositories to share common logic across the whole company, organization, or project. Monorepo makes it even easier to improve the DRY(ness) of your code as we can not just reuse common patterns, components, and types across different Front-end libraries but between Front-end and Back-end as well.
Atomic changes - When making changes that would affect other projects/libraries (like an API definition), all those changes can be applied and tracked on a single branch/commit without having to track down all dependent projects and additional coordination efforts necessary.
Standardization - It is easier to standardize code and tooling across the teams. You can impose branch policies to keep your main branch clean, limit access to specific branches, enforce naming guidelines, include code reviewers, and enforce best practices while sharing the same linter and prettier configurations on multiple projects and libraries in your repository.
Release management - You can handle all your release pipelines once without having to set up over-complicated deployment sequences across repositories using a clear and defined flow that every team can follow and avoiding the deployment knowledge within each team.
Easier refactoring and dependencies - Direct access to all micro-services makes refactoring the code in a Monorepo and changing the overall code structure much quicker than moving code between repositories. By updating the dependencies on the same repository, it is easier to avoid version conflicts between libraries.

But why use Nx and not just create a simple angular or react workspace? What sets Nx apart is the extensive toolset that it brings to the table, helping you across all the facets of building your Monorepo. Here are some of the valuable features of Nx :

Cached and Custom Operations - Nx will allow you to define and cache operations avoiding the same code being built multiple times. When making changes to a library, you can automatically execute operations (like building, testing, linting, etc.) on affected projects, significantly reducing build times or pipeline executions.
Cross framework components - Another great feature coming with Nx is the possibility to build micro Front-ends and share the same component across React and Angular applications. You will code your component logic once and use it as is in your project. Additionally, all projects and libraries will be created with testing tools like Cypress, Storybook, and Jest.
Easy to manage dependencies - Nx also extends some eslint rules to allow you to carefully decouple and isolate your library and dependencies. With the tags system and dependencies tree, you can enforce the dependencies flow you like across your projects/libraries. Nx will help you find circular dependencies or dependencies that make no sense (for example, a library depending on a project). To have a quick glimpse of your project structure, you can generate a dependencies graph of the workspace.
A Configurable CLI - Nx comes with a robust CLI that can be configured to work with different tools and even different languages providing commands to operate and manage all the chunks of your codebase. For example, If you are familiar with angular CLI, Nx will extend those commands to work with the whole NX Monorepo.
Metadata-driven - Everything in Nx comes with metadata to enable tool-ability. The default values, validations, auto-completion, and other settings are all defined in a schema instead of code. You can also use the Nx Editor Plugin and change his configuration with those files.

2. Why did we choose Nx for AnyLogi

Anylogi is a Logistics Management Platform connecting brands with WMSs, warehouses, and delivery companies worldwide. The Front end is built in Angular, with a NestJs application serving as a gateway to our Back-end. Since the application requires connection to multiple WMS with different guidelines and requirements, we decided to make the logic decoupled as much as possible. This would also come in handy since our app consists of various user types with different permissions and functionality.

In previous projects I worked on, the basic approach to handle such cases was to create an Angular directive hiding or showing some UI elements, with conditions in code for calling or not some API. But such an approach makes scalability very difficult. The more User Roles added, the more conditions and logic were added to the FE, making it hard to maintain and test the multiple cases. Another issue we faced was when creating customized user roles functionality and experiences. In some cases, we wanted error messages for the admins to be more detailed than for users. In other, we would show advanced steps or fields for admins while simplifying the same process to users. All those changes would add additional conditions and fragment our application in parts that were not working together in harmony.

With Anylogi, we decided to follow the Monorepo approach. Instead of having a single project with a hard-to-grasp logic and conditions all over the place, or multiple repositories that would need to work as one, we built a single Monorepo with Nx to handle our various projects and libraries. It makes things quicker and easier when sharing common logic, modules, and features across our workspace while maintaining the ability to easily customize the experience of a specific user type.

We created three projects based on our user roles requirements and desired experience. We separated some common components used in those three projects (like the headers, logins pages, etc.) in UI libraries used across all projects. Finally, We separated our feature logic into various feature libraries, that way, it would be simple to add or remove functionality when needed.

Thanks to Nx cached operations, we can modify a single Front-end app and deploy it independently of the others, or modify a library, rebuild the dependencies and deploy only that library-affected apps.

One thing we missed and might add later is the addition of our NestJS gateway to this mono repository. Right now, our Back-end Gateway exists on a different repository, which creates some code duplication, but it would work all the same, if not better, if we added it in our Monorepo.

3. Create A Simple Nx Monorepo

In this last part, we will create a simple Nx Monorepo with a project depending on a library. We are going to use angular, but you are free to set up React or View.
Be sure to replace by what you want the content between bracket { }.

Let’s start by creating our workspace.

npx create-nx-workspace@latest

You will have to choose the workspace's name, what to create in it, and additional options based on what you selected. I chose angular for this example, but you can use whatever you want or add new projects and libraries later. You will also be prompted to use Nx Cloud, I will not go over it in this blog, but you can find more information on the Nx website Nx Cloud

You can test the project by navigating in the workspace and launch the project (those names are the ones you set previously) :

cd ./{workspaceName}/
npx nx serve {applicationName}

you should see on http://localhost:4200/ the default Nx start page:

Let’s now add a library :

npx nx g @nrwl/angular:lib {libraryName}

This will generate a new folder under libs named like your library and will contain the code defining your library. By default, this will result in an angular module named like the library. But Nx will also add additional configuration in your workspace, the most crucial part being the following.

If you go to the tsconfig.base.ts at the root of the project, you will see a new line added that should look like (with the name you selected) :

"paths": {
    "@{applicationName}/{libraryName}": ["libs/{libraryName}/src/index.ts"]
}

This absolute import path points to your library definition. Anything exported in this file will be sharable across your workspace.

For Nx to work correctly and your project to be clean, ANYTHING that you want to export from the library should be present in this file. Additionally, EVERY project that uses this library must ONLY import and use what is defined in this file.

Let's add a component to this library. We will use the Nx CLI to generate the boilerplate the same way Angular CLI does it. I usually use Atomic Design to organize my components, but for the sake of simplicity, let’s add it at the root of the library.

cd ./libs/{libraryName}/src/lib/
npx nx g @nrwl/angular:component {componentName}

Voila! We created a component the same way we usually do, and it is already declared in the library module. Let's add some code to this component at the top of the Nx demo page. I will create a simple text header.

in the .html

<div class="topnav">
   Library Header
</div>

in the .css (or whatever per-processor you chose)

.topnav {
   background-color: rgb(94, 94, 255);
   overflow: hidden;
   width: 100%;
}

Double-check if the component is correctly added to the library module using the name you have previously chosen for your library and component. In my case, it looks like this :

`@NgModule({
    imports: [CommonModule],
    exports: [HeaderComponent],
    declarations: [HeaderComponent],
})
export  class  SharedUiModule {}`

index.ts
export * from './lib/shared-ui.module';

Check also that the module is exported in the library entry point (index.ts). If yes, let's import our library into our main project.

Navigate to the AppModule of our application and import our library module by using the ABSOLUTE PATH

Now add our component in our project app.component.html, and you should see it appear :

You can now also use

npx nx dep-graph

to generate the simple dependency graph of our project :

You can find this very simple Monorepo here https://github.com/Crocsx

4. Conclusion

There is a lot more you can set up on NX to make your project easier to manage, and we only scratched the surface. I hope this short blog post gives you enough information to understand the basics and the possible applications of such a tool for your future project. I hope to go more in detail in a future blog post and showcase much more functionality. Until then, have a great one!

Remove automatic zoomIn of inputs on IOS

Federico Giacomini — Tue, 11 May 2021 04:28:55 +0000

Hello, First post here.

I decided to use this platform to write reminders for myself, and quick tips to help everyone during daily development.

Today I had to face a problem on IOS where Safari decides to auto zoom on inputs when user click on them.

This happens when the font-size is considered too small by Apple (because yes, they decide what they want for you always right ?) which is apparently 16px.

Anyway, after searching over the internet for quite some times, and finding posts ranging from 2014 to today, I ended up with this simple solution.

  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no" />
    <script>
      const el = document.querySelector('meta[name=viewport]');
      const isIOS = /iPad|iPhone|iPod/.test(navigator.userAgent) && !('MSStream' in window);
      if (isIOS) {
        const metaViewport = document.querySelector('meta[name=viewport]');
        metaViewport.content =
          'width=device-width, initial-scale=1, shrink-to-fit=no, minimum-scale=1, maximum-scale=1';
      }
    </script>
  </head>

The important part is to add minimum-scale=1, maximum-scale=1 ONLY for IOS. This will allow your users on desktop/android/iOs to correctly use the app without affecting their ability to manually zoom. And remove only the automatic zoom behavior of Apple devices.

Hope this helps

You can find a lot of ideas on this SO post (included the answer I followed)

https://stackoverflow.com/questions/2989263/disable-auto-zoom-in-input-text-tag-safari-on-iphone