joey devilla headshot 900px

I’m a Senior Developer Advocate at Auth0, and I like to work on various technologies. I’ve developed software for all sorts of platforms, from CD-ROM and the PalmPilot to my current area of focus, mobile phones, IoT devices, and AI. When I’m not looking for strange new platforms to write software for, I’m playing a strange old instrument — the accordion!

Senior Developer Advocate

Joey deVilla

peterfernandez_360

As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams deal with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.

Principal Developer Advocate

Peter Fernandez

Add personalization to your iOS/SwiftUI app with user info from the ID token, a JWT (JSON Web Token) that you’ll read with the Swift JWTDecode library.

In Part 1 of this tutorial, you created a SwiftUI-based iOS app that uses Auth0 for basic login and logout functionality. In this part, you’ll enhance your app by giving it the ability to read the user’s profile to display their photo, name, and email address when they’re logged in.

<include 
    src="LinkCard" 
    title="Calling a Protected API from an iOS Swift App" 
    link="https://auth0.com/blog/calling-protected-apis-from-ios-swift/" 
    description="Looking for a step-by-step guide to leveraging OAuth 2.0 when accessing protected APIs via an iOS app built with Swift? If you're integrating with Auth0, then this is everything you need to know!"     img="https://images.ctfassets.net/23aumh6u8s0i/5PC3nu1F68m8S3BmJFv9SN/e83487c6d89d72fb6a49155722959b1d/ios_hero_2021_2.jpeg"
/>

Once again, you can follow the text in this article, or if you prefer learning by video, you can follow the steps in this article’s companion video:

<iframe width="600" height="338" src="https://www.youtube.com/embed/xOBoLegDmTw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

> Look for the 🛠 emoji if you’d like to skim through the content while focusing on the build and execution steps.
> 
> The 📺 emoji highlights links to specific points in the video.


## Examine the ID Token

📺 [The _Examine the ID Token_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2008s)
 
If you look at the `.success` case of the `switch` statement in `ContentView`’s `login()` method, you’ll see these `print()` functions:

```swift
print("Credentials: \(credentials)")
print("ID token: \(credentials.idToken)")
```

These functions’ output will appear in Xcode’s Debug area:

![Xcode screenshot highlighting the Debug area.](https://images.ctfassets.net/23aumh6u8s0i/2Odv2P2CeeMGBoKSHNl3ly/2ba5ae37dbc5afafb94e82f95f41a722/debug_area.png)

> If the Debug area isn’t visible, open the _View_ menu and select _Debug Area_ → _Show Debug Area_ or use the keyboard shortcut _command-Shift-Y_.

You’ll see the contents of the `credentials` object and its `idToken` property, which should look similar to this:

```
Credentials: Credentials(accessToken: "<REDACTED>", tokenType: "Bearer", idToken: "<REDACTED>", refreshToken: nil, expiresIn: 2022-03-20 04:38:25 +0000, scope: Optional("openid profile email"), recoveryCode: nil)
ID token: eyJhbGciOiJSUzI1NiIsInR5cC...
```

The `credentials` object is a package of information that Auth0 sends to your app after authenticating a user. This information includes:

- **ID token:** Data that proves that the user has been authenticated.
- **Access token:** Data that gives a client application permission to access a specific resource to perform specific actions on the user’s behalf.
- **Refresh token:** Applications use this to get additional access tokens when the original access token expires without requiring the user to re-authenticate.
- **Scopes:** A set of [OpenID Connect (OIDC) scopes](https://auth0.com/docs/get-started/apis/scopes/openid-connect-scopes) — authorizations for access to details about the user — that Auth0 has granted to the app. Unless you specify otherwise, *Auth0.swift* defaults to requesting the following scopes when logging in a user:
	- `openid`: Authorization to use OIDC to verify the user's identity
	- `profile`: Authorization to access the user’s name information
	- `email`:  Authorization to access the user’s email address

> Want to know more about ID tokens and access tokens? We explain all in our article, [_ID Token and Access Token: What's the Difference?_](https://auth0.com/blog/id-token-access-token-what-is-the-difference/)
> 
> Want to know more about refresh tokens? See our article, [_What Are Refresh Tokens and How to Use Them Securely_](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/).

The piece of information that we’re most interested in (for this exercise) is the ID token.

When the `print()` function is used to output the contents of `credentials`, the values of the `idToken` and `accessToken` properties are replaced with the string `<REDACTED>` as a security measure. Malicious parties can use tools to capture the output of `print()` functions from production apps; this is why `Credentials` instances redact the values of their `idToken` and `accessToken` properties when printed.

Note that when we use the `print()` function to output `credentials.idToken` — the ID token itself — the value is _not_ redacted. That’s because this value is useful for debugging, which we’ll do in the next step.

> It’s fine to print the value of the ID token to the debug console while you’re learning about the authentication process or building the app. Make sure you remove `print()` statements — especially those that print sensitive information, such as the ID token — before putting them into production!


### What’s in the ID token?

📺 [The _What’s in the ID token?_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2118s)

To see what’s in the ID token, copy its value from the Debug area, go to Auth0’s [JWT.io site](https://jwt.io/) and paste that value into the _Encoded_ text area on the left side of the page. JWT.io will decode the ID token from its JWT form and display its decoded contents in the _Decoded_ area on the page’s right side:

![JWT.io and the decoded ID token.](https://images.ctfassets.net/23aumh6u8s0i/4sg6VirydfCzVVenH6LWil/174552abed55b4fe3d8100493c1510db/jwt.io_screenshot.png)

In the _Decoded_ area’s _Payload_ section, you’ll see the decoded user information from the ID token, including the data that we want the app to display: the user’s name, email address, and picture.

In the next step, we’ll give the app the same ID token-decoding capability as JWT.io’s.

> Auth0 has plenty of information about JWTs. In addition to the main [JWT.io page](https://jwt.io/), you should visit JWT.io’s [_Introduction to JSON Web Tokens_](https://jwt.io/introduction) and download our [free JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook).


## Get the User’s Information

📺 [The _Get the User’s Information_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2223s)

The app only “knows” whether the user is logged in or logged out in its current state. It also has information about the user’s identity encoded in the ID token. Let’s extract this user information — the *user profile* — and use it to display the user’s name, email address, and picture when the user is logged in. 

🛠 In `Profile`, add the following `import` statement before the `struct Profile` line:

```Swift
// [ 📄 Profile.swift ]

import JWTDecode

// [ More code here ]
```

🛠 In the `Profile` extension, replace the `// TODO: Implement the 'from()' method.` comment with this `from()` method. It uses a couple of methods from the newly-imported `JWTDecode` library:

```swift
// [ 📄 Profile.swift ]

// [ More code here ]

  static func from(_ idToken: String) -> Self {
    guard
      let jwt = try? decode(jwt: idToken),
      let id = jwt.subject,
      let name = jwt.claim(name: "name").string,
      let email = jwt.claim(name: "email").string,
      let emailVerified = jwt.claim(name: "email_verified").boolean,
      let picture = jwt.claim(name: "picture").string,
      let updatedAt = jwt.claim(name: "updated_at").string
    else {
      return .empty
    }

    return Profile(
      id: id,
      name: name,
      email: email,
      emailVerified: String(describing: emailVerified),
      picture: picture,
      updatedAt: updatedAt
    )
  }
  
// [ More code here ]
```

Given an ID token string, the `from()` function creates a `Profile` instance. If `from()` can extract claims — values about the user’s identity, which include their name, email address, and the URL for their picture — from the ID token, it returns a `Profile` instance with that information in its properties. Otherwise, it returns a `Profile` instance with empty properties.


## Display the User’s Information

📺 [The _Display the User’s Information_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2424s)

Now that there’s a way to extract information from an ID token, let’s put it to use. 

Since `userProfile` is marked with the `@State` attribute, it defines the user interface’s state. Whenever `userProfile` or one of its properties changes, the app redraws the user interface to reflect the change.

We want to display the user’s information when they log in, so we’ll use `Profile`’s newly-created `from()` method in the `login()` method.

🛠 Open `ContentView` and update `login()` as shown below:

```swift
// [ 📄 ContentView.swift ]

// [ More code here ]

  func login() {
    Auth0 // 1
      .webAuth() // 2
      .start { result in // 3
        switch result {
          // 4
          case .failure(let error):
            print("Failed with: \(error)")
          // 5
          case .success(let credentials):
            self.isAuthenticated = true
            // 👇🏽👇🏽👇🏽 New line of code here!
            self.userProfile = Profile.from(credentials.idToken)
            // 👆🏽👆🏽👆🏽
            print("Credentials: \(credentials)")
            print("ID token: \(credentials.idToken)")
        }
      }
  }

// [ More code here ]
```

The newly-added line of code runs after the user logs in, and the app receives the ID token. It creates a new `Profile` instance from the data in the ID token and sets `ContentView`’s `userProfile` property to that instance.

When the user logs out, we should clean up the user profile just to be safe.

🛠 Update `logout()` as shown below:

```swift
// [ 📄 ContentView.swift ]

// [ More code here ]

  func logout() {
    Auth0
      .webAuth()
      .clearSession { result in
        switch result {
          case .success:
            self.isAuthenticated = false
            // 👇🏽👇🏽👇🏽 New line of code here!
            self.userProfile = Profile.empty
            // 👆🏽👆🏽👆🏽

          case .failure(let error):
            print("Failed with: \(error)")
        }
      }
  }

// [ More code here ]
```


## Run the App Again

📺 [The _Run the App Again_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2566s)

Run the app and confirm that the changes work. When you log in, you should see the user’s name, email address, and picture:

![The app’s “logged in” screen, featuring the text “Logged in” and displaying the user’s picture, name, and email address.](https://images.ctfassets.net/23aumh6u8s0i/1zYLUYAU3fdbLLde9PmhCN/90854331950e7557fbcc52db5bcb7379/logged_in_screen.png)

Congratulations, and high-fives and handshakes all around! You’ve taken a SwiftUI app and given it the ability to authenticate users with Auth0.


## Next Steps

SwiftUI is an expansive topic; we only scratched its surface in this tutorial. For your next steps in exploring it, you might want to look at these valuable resources:

- [SwiftUI by Example](https://www.hackingwithswift.com/quick-start/swiftui)
- [Your First SwiftUI App](https://www.youtube.com/watch?v=VlhcNR7Qrno)
- [Stanford University’s “Developing Applications for iOS” course for Spring 2021](https://www.youtube.com/playlist?list=PLpGHT1n4-mAsxuRxVPv7kj4-dQYoC3VVu)

📺 Last but not least, the video ends with [closing remarks and a quick accordion number](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2645s)!

Get Started with iOS Authentication using SwiftUI, Part 2: User Info, ID Tokens, and JWTs

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Andrea Chiarelli

Should developers know Identity protocols like OIDC and OAuth, or should they only rely on high-level abstractions like SDKs?

Do developers need to understand the underlying details of OpenID Connect, OAuth, and other standards to implement authentication and authorization? Maybe yes, maybe no. Let’s explore some different points of view.

## The Hard Journey to Identity

Sooner or later, a developer will have to deal with authentication and authorization, whether they are building a SPA, an API, a mobile app, or a microservice, whether they are using Java, C#, JavaScript, or other programming languages.

Some will probably try to implement a homemade solution because it is, after all, a simple login box 😱. And after overcoming the hurdle of username and password authentication, they face the burden of [single sign-on](https://auth0.com/docs/authenticate/single-sign-on), delegated authorization, [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication), and so on. Perhaps just by trying to build a homemade solution, they will understand the complexity of the problem and look for proven solutions.

As they learn about standards such as [SAML](https://auth0.com/blog/how-saml-authentication-works/), [OIDC](https://auth0.com/docs/authenticate/protocols/openid-connect-protocol), [OAuth](https://auth0.com/docs/authenticate/protocols/oauth), [WebAuthn](https://auth0.com/docs/secure/multi-factor-authentication/fido-authentication-with-webauthn), etc., they will probably realize that they have tried to reinvent the wheel. And most likely, they have not considered scenarios that could compromise the security of their application.

But even if you look at these standards from a high level, you will realize that there are many facets, many different scenarios to consider, several details and nuances.

In summary, sooner or later, developers will learn that Identity management is hard.

## To Know or to Ignore? That Is the Question

Once they understand that following standards is the high road to managing the identity of their application users, developers are at a crossroads:

1. Understand and implement the details of these standards.
2. Use a library or SDK and completely ignore the underlying complexity.

The two options seem divergent: know the details or ignore them altogether. Perhaps they reflect the two approaches that developers can take to deal with standards, not just in the Identity space. The choice may depend on the developer's inclination but also on other factors, such as competencies, available time and budget, and so on.

### Developers don't care...

[Someone has argued](https://developer.okta.com/blog/2019/01/23/nobody-cares-about-oauth-or-openid-connect) that "*99.99% of developers out there don’t know (or want to know) anything about OAuth, OIDC, or any other security specifications. All they want to do is find the simplest and most straightforward way to support user authentication and authorization in their application. They don’t care about standards, specifications, grant types, JWTs, or scopes and timeouts – all they want to do is log a user in and check to see what permissions they have.*"

That's pretty understandable. As a developer, I want to solve my problem as quickly as possible without getting lost in the details. If I'm developing an e-commerce application, I want to focus on the business logic of my application. I don't want to worry about every technical detail that my application relies on. I don't want to know the little internal details of the framework my application runs on, the necessary compilation steps, or the network infrastructure that it will use. I prefer to use tools that take care of that and abstract the internal behavior. Tools that are accurately built by real experts in their field. After all, that is what we at Auth0 are trying to do: take care of the complexity of Identity and free developers from knowing the details of standards and security issues.

### ...developers do care

On the other hand, there are [those who argue](https://www.scottbrady91.com/oauth/why-developers-do-care-about-oauth-and-openid-connect) that "*there is an appetite from developers to learn more about OAuth and OpenID Connect and how to use them effectively. So maybe it’s a little too much to state that developers don’t care.*"

Well, in my experience, that is also true. I've found a lot of developers trying to understand how to properly use an [access token](https://auth0.com/docs/secure/tokens/access-tokens) and which [OAuth flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) to use in a given scenario, even if they're using a third-party library. And I think that's pretty understandable as well. While I don't want to learn every little detail of the infrastructure my application will run on, I can't ignore it completely. Some features of my application might depend on it to work well.

So, what is the right choice to make when dealing with standards in the Identity management space (and also in other areas)? Know their details or ignore them?

<include src="ebook-ads/JwtHandbook" />

## The Third Way

“[Zen and the Art of Motorcycle Maintenance](https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance)” is one of the cult books of the 1970s. It is a kind of philosophical novel in which the author, [Robert M. Pirsig](https://en.wikipedia.org/wiki/Robert_M._Pirsig), explores the concept of quality by interweaving it with his almost-fictional biography and his passion for motorcycles.

### Two types of developers

In one of the book's disquisitions, the main character divides humanity into two types:

- Those who see the world as a complex mechanism to be explored in its inner workings (*classical understanding*).
- Those who see the world primarily in its superficial appearances (*romantic understanding*).

Romantic people are those who ride their motorcycles without worrying about how they work. They are not interested in the mechanics of the drivetrain or the ignition or the lubrication system. If their motorcycle breaks down, they take it to the mechanic. And they hardly hear in advance that something is going to break down.

Classical people are those who feel their motorcycle. When they ride it, they hear every little noise, they imagine the movement of the chain, they are one with their means of transportation. They feel when something is about to go wrong because they know every little part of their bike and prefer to fix it themselves.

These two categories of people also apply to developers, in my opinion. Romantic developers don't care about the underlying technology or standard. They want to use a library that simplifies their lives and gets right to the point. Classical developers, on the other hand, want to know what happens inside a library: what technology, standard, and algorithm it uses. Classical developers are the traditional hackers, the ones who get their hands dirty with grease to fix or customize the engine of their motorcycle.

Maybe the choice between the two options for dealing with Identity management is driven by these two developer personalities. And perhaps each of you can identify with one of these two profiles.

<include src="BigQuote" quoteText="Although motorcycle riding is romantic, motorcycle maintenance is purely classic." quoteAuthor="R. M. Pirsig" />

### In medio stat virtus

Starting from a *classical* position, the protagonist realizes that virtue lies in the middle, just as the Latins used to say (*in medio stat virtus*). And virtue, excellence, quality is what he is looking for: what the ancient Greeks called *areté* and Eastern cultures call *Dharma*.

While each developer tends to use a romantic or classical approach to the Identity management problem, based on their personal nature, I think that each of the two positions should only be a starting point.

If Identity management is not your business, it is not cost-effective to implement standards from scratch and take care of all the details. Standards evolve, as do scenarios, best practices, etc. If your core business is not Identity management, implementing OIDC, OAuth, and the other standards may be too expensive and risky for your project.

On the other hand, simply using a library or SDK and ignoring what lies beneath it cannot last long. It can be frustrating when problems occur and you have no idea what is going on. You don't know if the problem depends on your code, your configuration, your library, the environment your application is running in. Understanding at least at a high level how the library you are using works and what standards it uses can help you at least to narrow down the area of investigation when problems occur.

In summary, I think every developer has their own starting point for dealing with problems. But whether you decide to do everything yourself based on standards or prefer to ignore everything under a library, in either case, it will impact the cost of your application.

I think the best solution is to get a medium level of expertise in technologies and standards so that you can at least choose your library with knowledge. What do we call this type of developer? The *pragmatic developer*?

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## What Auth0 Offers

Whether you are a romantic or classical developer, Auth0 helps you integrate authentication and authorization into your applications by letting you use the approach you prefer.

You have [SDKs and libraries](https://auth0.com/docs/libraries) that abstract the complexity of Identity management, but you are not locked into using our libraries. Your choice is free. But you can look into [our code](https://github.com/auth0) and contribute.

You also have [documentation on standards](https://auth0.com/docs/authenticate/protocols), [guides](https://developer.auth0.com/resources/guides) specific to your favorite framework, [code samples](https://developer.auth0.com/resources/code-samples), [videos](https://www.youtube.com/oktadev), and a [community](https://community.auth0.com/) to share what you've learned.

You can choose your preferred path to becoming a *pragmatic* developer by taking advantage of the resources Auth0 provides.

What kind of developer are you? Are you romantic or classical? Are you aiming to become a pragmatic developer? How can we help you? Leave your comments below.


Zen and the Art of Identity Management

manfred

Under the leadership of Manfred Steyer, ANGULARarchitects.io supports companies with the implementation of web-based business applications with Angular. <br>
 
At the Angular seminars he designs, he combined his profound knowledge of Angular, for which he was recognized by Google as a Google Development Expert (GDE), with his experience, which he worked as a team leader in the field of software development, as a Professor at a university of applied sciences and as an external member of the Angular team. <br>
 
Manfred has published books at O'Reilly, Microsoft Press, and Hanser and writes for Heise Online, windows.developer, and the Java magazine. He also regularly shares his knowledge at conferences.

Trainer and Consultant with focus on Angular

Manfred Steyer

Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

**TL;DR:** Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

## Micro Frontends

Recently, there have been a lot of discussions about Micro Frontends. The underlying idea is quite tempting: Splitting a huge software system into smaller parts and assigning each part to an individual team:

![Each micro frontend can be developed by an autarkic team](https://images.ctfassets.net/23aumh6u8s0i/38DpehwkPwiMTNBOvOQowG/ce345e71277e19f211f23add38a0ae4e/microfrontends.png)

As these teams are -- more or less -- autonomous, they can work in a more flexible way and don't need to coordinate that much with others. This shows that Micro Frontends are mostly about scaling teams. Hence, if you don't have several frontend teams, Micro Frontends might be overkill. 

## Module Federation

Splitting software systems into several parts is, however, only one side of the coin. Even though we developers might like this idea, the users don't! They aren't interested in starting several frontends but expect an integrated solution. 

Accordingly, we need to find a way to make all our micro frontends appear as one (single page) application. Very often, this involves loading micro frontends into a shell application.

For instance, the example used here mimics a simple shopping system. One of its micro frontends deals with shipping:

![Example micro frontend dealing with shipping products](https://images.ctfassets.net/23aumh6u8s0i/3Zs0it0naO2U4W1GwBMpNn/caa76eb2a246ab2dfa5d5394c6ed89c5/example-shipping.png)

For the purpose of integration, this micro frontend needs to be loaded into a shell:

![Example of a shell loading the shipping micro frontend](https://images.ctfassets.net/23aumh6u8s0i/iJOA5Lg4AHYGHBt0SK06U/8bdb25c11b8ac571f259f57217ff72eb/example-shipping-in-shell.png)

The shell loads this but also other micro frontends on demand.

For such an implementation, you needed a lot of tricks in the past. Fortunately, Module Federation makes this task straightforward. 

Module Federation is an integrated part of webpack 5, and hence, it works with all modern web frameworks. Also, as webpack is highly used in nearly all communities, Module Federation immediately becomes a widespread solution.

In order to allow loading separately compiled and deployed micro frontends, Module Federation defines two roles: the host and the remote:

![Schematic representation of Module Federation](https://images.ctfassets.net/23aumh6u8s0i/6RTBbIScEwfnZm97MMe7nJ/2138d86c99a988b286f9852d020097a4/module-federation.png)

In our case, the host is the shell, while the remote is the micro frontend. Both can be configured with their webpack configurations. 

The host defines virtual URLs pointing to remotes. In the previous picture, for instance, the URL ``mfe1`` pointing to a micro frontend, also called ``mfe1``, is defined.

The remote, in turn, exposes files -- or, to be more precise: EcmaScript modules -- for the host. To prevent that, the latter one needs to know the remote's file structure; exposed files can get a shorter alias. The example in the last picture goes with the alias ``Cmp``. 

Exposed EcmaScript modules can easily be loaded into the host by using a dynamic ``import`` together with the mapped URLs and defined aliases. The best: From Angular's perspective, this is just like lazy loading. 

As Angular doesn't even recognize that the application loads a micro frontend, we can use it exactly as it was intended to be used. We don't need any tricks or meta frameworks orchestrating different SPAs in our browser window. This eases our endeavor dramatically.

## Module Federation in Angular

Since version 12, the Angular CLI uses webpack 5. Hence, we also get Module Federation out of the box. To activate it, we need a custom builder that, e. g. ships with the community solution ``@angular-architects/module-federation``. As it comes with respective schematics, you can easily ``ng add`` it to your CLI workspace:

```bash
ng add @angular-architects/module-federation
```

![Adding @angular-architects/module-federation to your project](https://images.ctfassets.net/23aumh6u8s0i/3eoqQDVCE5OK0QfzoYmXt8/378fda04d26bd28ffc798754f3150819/ng-add.png)

The well-known CLI extension [Nx](https://nx.dev/) is supported too. The schematic asks about the name of the project in your workspace you want to enable module federation for. Also, it asks which port to assign for ``ng serve``.

After that, it generates several files, e. g. a partial webpack configuration we need to adjust for our needs. Also, it registers the custom builder in our ``angular.json``.

For the example used here, I ran this command twice: Once for the shell and once for the above-shown shipping micro frontend. The latter one is just called ``mfe1`` here.

## Configuring the Micro Frontends

Now, we need to adjust the webpack configurations generated for the shell and the micro frontend. As the Angular CLI is generating most parts of the webpack configuration, we just need to define the remaining details for the module federation. First and foremost, this is about configuring the ``ModuleFederationPlugin`` that ships with webpack.

Let's start with the configuration for the micro frontend:

```javascript
// projects/mfe1/webpack.config.js

[...]
plugins: [

  new ModuleFederationPlugin({
    
      // For remotes (please adjust)
      name: "mfe1",
      filename: "remoteEntry.js",
      exposes: {
          './AddressModule': './projects/mfe1/src/app/address/address.module.ts',
      },        
      
      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true },

        ...sharedMappings.getDescriptors()
      })
          
  }),
],
[...]
```

The property ``name`` is normally the project name and should be unique across all micro frontends. The ``filename`` points to a file webpack generates when building the project. It's often referred to as the remote entry point. This JavaScript file provides all the metadata the shell needs to know for loading the micro frontend.

While normally you can go with the generated values for ``name`` and ``filename``, you very likely need to adjust the ``exposes`` section. As discussed above, it contains the aliases for the files to expose.

With ``shared``, you define all the npm packages you want to share across the shell and the micro frontends. These packages are only loaded once at runtime. This is vital because having ten micro frontends doesn't mean you want to load Angular or other packages ten times!

Of course, when sharing packages at runtime, we might end up with version conflicts. Fortunately, Module Federation also got us covered here: It provides several strategies for dealing with version mismatches. 

In our case, the combination of ``singleton: true`` and ``strictVersion: true`` is used. Hence, only one version of the shared packages is allowed, and if Module Federation detects several versions at runtime, it throws an Error. While this seems to be quite harsh at first sight, it allows our integration tests to immediately find out about version mismatches.

More details on [strategies for preventing version mismatches](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/) can be found [here](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/).

Besides ``singleton`` and ``strictVersions``, there are two further properties used: ``requiredVersion`` and ``includeSecondaries``. If we set the first one to ``auto``, ``@angular-architects/module-federation`` assumes the version found in your project's ``package.json``. This avoids several [pitfalls](https://www.angulararchitects.io/aktuelles/pitfalls-with-module-federation-and-angular/). 

The option ``includeSecondaries`` is provided by ``@angular-architects/module-federation`` too. It automatically adds all secondary entry points to the list of shared libraries. In the case of libraries like Angular Material, this saves you a lot of typing as they provide one such entry point per component, e. g. ``@angular/material/input`` or ``@angular/material/button``.

Now, let's have a look at the exposed ``AddressModule``: 

```typescript
// projects/mfe1/src/app/address/address.module.ts

[...]

@NgModule({
  imports: [
    [...]
    RouterModule.forChild([{
      path: 'address', 
      component: AddressComponent
    }])  
  ],
  declarations: [
    AddressComponent
  ],
})
export class AddressModule { }
```

As you see, it's just an ordinary Angular module. However, as it has child routes, we can immediately route to them after loading the whole module into the shell. 

## Configuring the Shell

The shell's ``webpack.config.js`` is a bit simpler. Here, we only need to define the shared libraries:

```javascript
// projects/shell/webpack.config.js

[...]
plugins: [
  new ModuleFederationPlugin({

      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true }

        ...sharedMappings.getDescriptors()
      })
      
  }),
],
[...]
```

In addition, we also could map URLs here, as outlined above. This would look like this:

```typescript
// Alternative that maps URLs upfront
new ModuleFederationPlugin({
  remotes: {
    "mfe1": "mfe1@http://localhost:3000/remoteEntry.js"
  },
  [...]
})
```

The key is the mapped URL, and the value defines the name of the micro frontend as defined in its ``webpack.config.js``. Here, the value also contains the location of the micro frontend's remote entry point. To load ``mfe1``'s exposed Module, we could use a dynamic ``import``:

```typescript
// Using mapped URL:
import('mfe1/AddressModule')
```

As the TypeScript compiler doesn't know the file ``mfe1/Module``, we also needed a type definition. For this, we could create an arbitrary with the ending ``.d.ts``:

```typescript
declare module "mfe1/AddressModule";
```

However, while mapping URLs this way is simple, it also requires us to know about the micro frontends and their locations upfront. Hence, I'm using a more dynamic approach that does not demand us to define URLs for compile time. 

Instead, we can tell Module Federation about possible Micro Frontends at runtime. To make use of it, I use the helper function ``loadRemoteModule`` provided by ``@angular-architects/module-federation`` together with lazy routes:

```typescript
// projects/shell/src/app/app.module.ts

[...]
RouterModule.forRoot([
  {
    path: '',
    component: HomeComponent
  },
  {
    path: 'mfe1',
    loadChildren: () => loadRemoteModule({
      remoteEntry: 'http://localhost:3000/remoteEntry.js',
      remoteName: 'mfe1',
      exposedModule: './AddressModule',
    }).then(m => m.AddressModule)
  }
])
[...]
```

The ``loadRemoteModule`` function takes the location of the remote entry point, the remote's name, and the alias of the exposed EcmaScript module. All these values are defined in the micro frontend's webpack configuration. 

As these properties are just strings, we could even retrieve their values from a configuration file or from a service endpoint.

## Trying It Out

After starting both projects, e. g. with ``ng serve shell, `` and ``ng serve mfe1``, we can use the lazy route shown above to load the micro frontend into the shell. It's also interesting to inspect the loaded files in your browser's dev tools:

![The browser loads the shared libraries](https://images.ctfassets.net/23aumh6u8s0i/5YzAFolOzvMYTspPsgZ5Wb/73d1fb9772e1128fca2eca404a1aa0ce/share.png)

At first sight, it really looks like lazy loading. However, when looking more closely, we see that the lazy chunks come from the micro frontend's origin. Also, for all the shared libraries, a bundle of its own is loaded. This is necessary because the module federation decides at runtime when to load which shared package. 

## Authentication for Micro Frontends

Sometimes we need to share some information between micro frontends and the shell, e. g. context information like the current user or global filters like the selected customer. The example used here allows logging in the user via the shell:

![Logging in the current user](https://images.ctfassets.net/23aumh6u8s0i/2XumqnUE2Cp56cB0nWJt2w/37480acbfca69c8036e36d38b94fbcd2/logged-in.png)

However, when loading the micro frontend on demand, it also knows about the current user:

![Sharing information about the logged in user](https://images.ctfassets.net/23aumh6u8s0i/2BdJ84YhuAxliC349B9A2Q/6294f33fd3d8b940789da984d41efe8c/logged-in-shipping.png)

To achieve this, we just need to share a package that holds the information to share. In our case, this is ``@auth0/auth0-angular`` as we are using Auth0 as our identity provider. It's available via npm:

```bash
npm i @auth0/auth0-angular
```

To make this work, I've configured a web application at https://manage.auth0.com/. If you want to try this out, don't forget to register your SPA's URL, e. g. http://localhost:4200, under _Allowed Callback URLs_. Besides this, I went with the default values proposed by the web portal.

To get started, we need to import the ``AuthModule`` provided by ``@auth0/auth0-angular`` into the ``shell``'s but also into ``mfe1``'s ``AppModule``:

```typescript
// projects/shell/src/app/app.module.ts
//  and
// projects/mfe1/src/app/app.module.ts

[...]

import { AuthModule } from '@auth0/auth0-angular';

[...]

@NgModule({
  imports: [
    AuthModule.forRoot({
      domain: 'dev-ha-6vf7s.us.auth0.com',
      clientId: 'pQXuZGn3bfOfHpFd9ch7Wfa4xP4KhKlS'
    }),
    [...]
  ],
  [...]
})
export class AppModule { }
```

The values for ``domain`` and ``clientId`` can be found at https://manage.auth0.com after registering your application.

After that, we can use the ``AuthService`` in the shell to login the current user:

```typescript
// projects/shell/src/app/home/home.component.ts

import { Component } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.scss']
})
export class HomeComponent {

  user$ = this.auth.user$;

  constructor(private auth: AuthService) {}

  login(): void {
    this.auth.loginWithRedirect();
  }

}
```

I also decided to display the user's name after they logged in:  

```html


<h1>Welcome!</h1>

<p *ngIf="user$ | async as user">
    User: {{user.name}}
</p>

<div>
    <button (click)="login()" mat-flat-button color="primary">Login</button>
</div>
```

In the micro frontend's ``AddressComponent``, I'm also using the ``AuthService`` to get some information about the current user:

```typescript
// projects/mfe1/src/app/address/address.component.ts

[...]

import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-address',
  templateUrl: './address.component.html',
  styleUrls: ['./address.component.scss']
})
export class AddressComponent {

  [...]

  constructor(
    private auth: AuthService,
    private fb: FormBuilder) {

    this.auth.user$.pipe(take(1)).subscribe(user => {
      if (!user) return;
      this.addressForm.controls['firstName'].setValue(user.given_name);
      this.addressForm.controls['lastName'].setValue(user.family_name);

    });

  }

  [...]
}
```

In order to make this work, we need to share the ``@auth0/auth0-angular`` package:

```javascript
// projects/shell/webpack.config.js
//  AND
// projects/mfe1/webpack.config.js

[...]
shared: share({
  [...]
  
  // Add this:
  "@auth0/auth0-angular": { singleton: true, strictVersion: true, requiredVersion: 'auto' },

  ...sharedMappings.getDescriptors()
})
[...]
```

This ensures there is only one ``AuthService`` at runtime we can use to share information about the current user. 

After changing the webpack configuration, we need to restart our applications. If everything works well, we can log in the user via the shell and read the user's name in the lazy loaded micro frontend.

## Summary

Module Federation allows loading separately compiled applications at runtime. Also, we can share common dependencies. This also allows sharing common data like information on the current user or global filters.

As Module Federation allows runtime integration, it is also the key for plugin systems and micro frontend architectures. However, this approach turns to compile-time dependencies into runtime dependencies; we need a sound set of integration tests to detect issues. 

In general, Micro Frontends only makes sense if you want to scale a project by splitting it into several smaller applications developed by different autarkic teams. If you only have one frontend team, Micro Frontend architectures are very likely an overhead.

Micro Frontends with Angular, Module Federation, and Auth0

500x500

I'm a software engineer, but I prefer to call myself Technology Bishop. Spreading knowledge through writing is my mission.

Software Engineer

Antonello Zanini

Let’s see everything you should know to start using Project Lombok. We will have a look at how to integrate it into your IDE and use it to avoid boilerplate code.

A Complete Guide to Lombok

facundo-giuliani

Facundo is a Systems Engineer from Buenos Aires, Argentina with 15+ years of experience in software development. Full Stack Developer. Auth0 Ambassador. GitKraken Ambassador. Cloudinary Media Developer Expert. He is also an open-source contributor.

Systems Engineer, Full Stack Developer

Facundo Giuliani

Besides surfing the web, you can use web browsers programmatically to automate tasks. Learn how to drive a Chromium browser using Puppeteer Sharp, a browser automation library for C#.

One of the goals every developer has is to automate as many actions and tasks as possible. Some of the reasons why we should try to automate our workflows are:

- We save work time.
- We depend less on human assistance.
- We make things faster.
- We spend less money.
- We get consistent results over iterations.

Besides the benefits that automation brings us, there are some scenarios that couldn't be achieved if we don't execute an automatic process. One example of this is the dynamic generation of files and images. In this article, we will see how to implement automatic workflows interacting with a web browser instance.

## Browser Automation

"Browser automation" is the action of automating the usage of a web browser. Its purpose is to achieve efficiency and speed at a certain level that wouldn't be possible if we rely on human interaction.

With a browser automation tool, we can simulate interactions using input devices (keyboard, mouse, etc.), or we can verify that visual elements are working and displayed correctly. We also have different elements inside a web page that we can interact with: dialogs, downloads, authentication forms, videos, etc.

With browser automation, we can do most of the things we do manually with a web browser. Some examples where we could use a browser automation API are:

- Automate form submission.
- Develop and implement a UI testing strategy using the latest version of Google Chrome Browser.
- Automate and validate keyboard input responses.
- Generate screenshot images.
- Generate PDF files.
- Scrape a website.
- Crawl a Single-Page Application (SPA) and generate pre-rendered content.
- Diagnose performance issues.

There are various browser automation tools in the market, implemented for several programming languages and with different features or purposes. One of the first to be released was [Puppeteer](https://pptr.dev/).

## What Is Puppeteer?

According to the official definition, [Puppeteer](https://pptr.dev/) is "A Node library which provides a high-level API to control headless Chrome or Chromium over the [DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/)".

A [headless browser](https://developers.google.com/web/updates/2017/04/headless-chrome) is basically a web browser without a graphic user interface. It renders HTML documents and executes JavaScript code, but without displaying it on the screen. We can interact with a headless browser through a command line.

Even though Puppeteer runs mainly as a headless Chromium instance, we have the possibility to set it as "non-headless" and display all the interactions on the screen.

## Puppeteer Sharp

Puppeteer Sharp is a .NET port of the official Puppeteer API. It can run on .NET Framework or .NET Core projects. As the library was developed with a C# focus, we can use it with features like dependency injection, Async suffixes, etc.

One cool thing is that Puppeteer Sharp supports Chromium-based browsers (Google Chrome, Microsoft Edge), but also Mozilla Firefox. So, we can automate interactions with those web browsers.

Let's play with Puppeteer Sharp and leverage it to generate content in PDF.

## PDF Generation App Using Puppeteer Sharp

Let's see how to generate PDF files with a C# console app using the [Puppeteer Sharp NuGet package](https://www.nuget.org/packages/PuppeteerSharp/). The application will receive a URL from the user; it will generate a PDF with the content of the website and will save the generated file in a defined directory.

If you want to see the final code of the application, download it from [this GitHub repository](https://github.com/auth0-blog/puppeteer-sharp-pdf-generator).

First of all, we'll create a new Console App.

![Create Console App in Visual Studio for Mac](https://images.ctfassets.net/23aumh6u8s0i/3AmUM3S7DrcgTm6o5hzv5E/640c7747f2e4922b1b1c4266c75d22a0/console-app.png)

After we named our application and generated the boilerplate code, we will add the "PuppeteerSharp" NuGet package to our solution.

![Add PuppeteerSharp NuGet package in Visual Studio for Mac](https://images.ctfassets.net/23aumh6u8s0i/1NumDfbWC4x7bLBB3fVdmx/20aa0a63fb1634341cc44a3d203c7ce8/puppeteer-sharp-nuget-package.png)

We will add the following code to the `Program.cs` file:

```csharp
using System;
using System.Threading.Tasks;
using PuppeteerSharp;

namespace PuppeteerSharpPdfGenerator
{
    class Program
    {
        static async Task Main(string[] args)
        {
            Console.WriteLine("Enter URL to generate PDF file:");

            string url = Console.ReadLine();

            var browserFetcher = new BrowserFetcher();
            await browserFetcher.DownloadAsync();

            await using var browser = await Puppeteer.LaunchAsync(new LaunchOptions { Headless = true });

            await using var page = await browser.NewPageAsync();
            await page.GoToAsync(url);
            await page.PdfAsync($"{DateTime.Today.ToShortDateString().Replace("/", "-")}.pdf");

            Console.WriteLine("PDF File generated successfully.");
            Console.ReadLine();
        }
    }
}
```

Let's detail what this code is doing:

- We start requesting the URL that we want to browse and print as a PDF file. We store that in the string variable `url`.

- We create an instance of BrowserFetcher. This class helps us to download the Chromium browser that we will use to automate our tasks.

- We call `browserFetcher.DownloadAsync` to download all the files related to the Chromium browser that we will use. You can see that the files are downloaded only the first time that we execute our app. In subsequent executions, we won't download anything.

- `DownloadAsync` method can receive a specific version of Chromium and run Puppeteer against it: for example, `await browserFetcher.DownloadAsync(533271)`.

- We launch the Chromium browser. `LaunchAsync` method has several parameters. We send `Headless = true` because we don't want to see how the browser operates while generating the PDF file. In case we want to see how it runs, setting `Headless = false` would be helpful.

- We open a new page in the browser and go to the URL entered by the user.

- We call ` page.PdfAsync` to generate the PDF file. The parameter is the filename we will assign to the newly created file.

- In case we want to change the browser's viewport before we generate the PDF file, we can call the `SetViewportAsync` method.

```csharp
await page.SetViewportAsync(new ViewPortOptions
{
    Width = 500,
    Height = 500
});
```

So, if we run our application, we will get this message in the Terminal:

![Terminal Requesting URL](https://images.ctfassets.net/23aumh6u8s0i/2IqgX4LqMijRA2lAneIRoG/931b63a0c3f136b20a88efe9972b0ff3/terminal-begin.png)

We will type a URL like "[https://jwt.io/introduction](https://jwt.io/introduction)" and press `Enter`. We should wait until the `PDF File generated successfully.` message appears on the screen and press `Enter` to exit from our app.

![Terminal PDF File Generated](https://images.ctfassets.net/23aumh6u8s0i/17k87SXzvMm7BNr1zDbQmA/5da168f22ac528b5ed7affc7a6324de2/terminal-pdf-generated.png)

After that, let's go to the directory where our app is located (if you are running or debugging it from Visual Studio, take a look at the `bin` directory inside the solution folder). We will see the generated PDF file, and if we open it, we will see the JWT tutorial page.

![PDF file showing the JWT tutorial](https://images.ctfassets.net/23aumh6u8s0i/46zAVG7OwOSf76GOOaCOEe/a20787ec65fc53592b0c9ae0ce9a4385/pdf-file.png)

## Summary

In this article, we talked about browser automation and how to implement it using Puppeteer Sharp, a .NET port of the Node.js library Puppeteer. We talked about different scenarios where we could automate browser tasks. We also talked about the "headless browser" concept. Finally, we created a sample application to show how to generate PDF files using Puppeteer Sharp from a C# console application.

If you want to learn more, explore other features and methods of Puppeteer Sharp, or see example code for other scenarios and usages, you can visit the [official GitHub repository](https://github.com/hardkoded/puppeteer-sharp).

<include src="asides/DotNetCore" />

PDF Generation with Puppeteer Sharp

Automating web browser interactions is a great way to test the functionalities of our web application. Let's see how to create UI tests in C# using Playwright Sharp, a browser automation library.

While creating web applications, we want to release them with as few errors as possible. We also want to make sure that the new functionalities we add to our apps don't break the existing behavior and workflows. The only way we can do that is by testing the different scenarios our apps support.

While our code base gets bigger and bigger, it gets pretty hard to manually go through the different paths our app offers every time we apply changes and edits. And even if we are coding a small web application, manual testing executed by a person may not always be the best solution. That is why having automated tests that run periodically through our apps is always a recommended idea.

We talk about User Interface testing when we want to test the visual aspects of an application. We do this to verify that the parts of our product that users will interact with are working as expected, and they meet the performance and functionality requirements.

We can create automatic processes and algorithms, probably using mock data, that execute [unit and integration tests](https://auth0.com/blog/xunit-to-test-csharp-code/) across our codebase. Doing this, we verify that everything is working as expected, and we are supporting all the logical scenarios and business rules our application handles. But if we want to test visual elements from our apps, we will need the help of a web browser.

## What Is Browser Automation?

As developers, we (should) always try to automate things. We make things faster, we save work time, we spend less money, we depend less on human assistance, we get consistent results over iterations.

If we want to create and run UI tests for our web apps, we should automate actions related to web browsers. We will need to simulate interactions using input devices (keyboard, mouse, etc.), and we will verify that visual elements are working and displayed correctly.
"Browser automation" is automating the usage of a web browser. The goal is to achieve efficiency and speed at a certain level that wouldn't be possible if we depend on human interaction.

There are different tools available to accomplish browser automation, implemented in different programming languages and with different features. Today we will talk about Playwright and the .NET implementation: Playwright Sharp.

## What Is Playwright?

[Playwright](https://playwright.dev/) is an [open-source](https://github.com/microsoft/playwright) browser automation library. It is a JavaScript-based library created to be used with Node.js. One of the main differences with other browser automation tools is that Playwright is cross-browser. It can automate tasks using Chromium (Google Chrome, Microsoft Edge), WebKit (Apple Safari), and Mozilla Firefox browsers, all with the same API.

Playwright was created by Microsoft. It was developed based on [Puppeteer](https://pptr.dev/), and it was improved to perform automatic UI testing.

Some of the benefits Playwright offers are:

- Support for all browsers
- Test for mobile using device emulation
- Cross-platform WebKit testing
- Headless and headful execution: while automation is being executed, you can hide (headless) or show (headful) the web browser UI. Headful is usually selected for debugging, while headless is the preferred option for continuous integration or cloud executions.

<include src="TweetQuote" quoteText="Playwright Sharp ports the power of browser automation to .NET." />

## What Is Playwright Sharp?

[Playwright Sharp](https://github.com/microsoft/playwright-sharp) is a .NET porting for Playwright. It works close to the product, so we have all the features from the original library available to be used in .NET.

Playwright Sharp has been built with C#, so developers can get the advantage of .NET features such as dependency injection, "Async" suffixes, etc.

The NuGet package has two required dependencies: the Playwright driver and the browsers that we can use. Playwright drivers will be copied to the bin folder at build time. The browsers are installed in different ways depending on the use we give to the library. If we want to use Playwright Sharp in test projects, browsers will be installed at build time.

Let's create an example project to use some of the features Playwright Sharp offers.

## Playwright Sharp in Action

To get acquainted with Playwright Sharp methods and features, we will create a small end-to-end test. End-to-end testing is a technique that tests a complete workflow, from beginning to end, to ensure the flow behaves as expected. The idea is to test real scenarios to verify that everything is working as expected.
For this article, we will test part of the [Auth0 website](https://auth0.com/). Let's say that we want to test if a particular Quickstart guide is working, and the link to the GitHub repository where the sample code lives is correct. Let's pick ["Regular Web App" for ASP.NET Core](https://auth0.com/docs/quickstart/webapp/aspnet-core).

If you want to see the final code of the project we are going to create, download it from [this GitHub repo](https://github.com/auth0-blog/playwright-sharp-auth0).

First of all, we need to create a project using a testing library to code and run our tests. You can choose any testing library you want that works with .NET Core and C#. For this example, let's create a new [NUnit](https://nunit.org/) Test Project.

![NUnit Test Project in Visual Studio for Mac](https://images.ctfassets.net/23aumh6u8s0i/5I32SOweWF4ndmTeapbNP9/82198c8a017365acd1e69073c86f1f77/nunit-test-project.png)

Once the project is created and the standard files are generated, let's add the "PlaywrightSharp" NuGet package to the project.

![Playwright Sharp Nuget Package in Visual Studio for Mac](https://images.ctfassets.net/23aumh6u8s0i/6DO9jJ8OSwyKPMGDrtTSNa/2e6740b35a1e5c562619b5b3af37abfb/playwright-sharp-nuget.png)

We will create only one test, so we will use the `UnitTest1.cs` file already generated and replace its content with the following:

```csharp
// UnitTest1.cs

using System.Threading.Tasks;
using NUnit.Framework;
using PlaywrightSharp;

namespace PlaywrightSharpAuth0
{
    public class Tests
    {
        [Test]
        public async Task Auth0RegularWebAppASPNETCoreLinkWorks()
        {
            using var playwright = await Playwright.CreateAsync();
            await using var browser = await playwright.Chromium.LaunchAsync(headless: true);

            // Go to Auth0 home page
            var page = await browser.NewPageAsync();
            await page.GoToAsync("https://auth0.com/");

            // Click on the cookie policy acceptance button if it exists
            if ((await page.QuerySelectorAsync("#truste-consent-button")) != null)
            {
                await page.ClickAsync("#truste-consent-button");
            }

            // Hover on Developers
            await page.HoverAsync("li[aria-labelledby='nav-item-Developers']");

            // Click on Quickstarts
            await page.ClickAsync("a[href='https://auth0.com/docs/quickstarts/']");

            // Hover on Regular Web App
            await page.HoverAsync("div[data-type='webapp']");

            // Click on Launch Quickstart
            await page.ClickAsync("div[data-type='webapp'] button.btn-success");

            // Search for ASP.NET Core
            await page.TypeAsync("div.quickstart-search-input input", "ASP.NET Core");

            // Click on ASP.NET Core logo
            await page.ClickAsync("div[data-name='aspnet-core']");

            // Look for "View on Github" button and get the href property
            var gitHubLink = await page.EvalOnSelectorAsync<string>("a.btn-transparent.btn-block", "e => e.getAttribute('href')");

            Assert.AreEqual(gitHubLink, "https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/Quickstart/01-Login");
        }
    }
}

```

Let's talk about the different methods used in the test.

- We create a Playwright instance that allows us to launch a web browser.
- For this example, we launch Chromium, the core of browsers like Google Chrome and Microsoft Edge. `LaunchAsync` method has several parameters. We use `headless: true` because we don't want to see how the browser operates while executing the test. If we set `headless: false` instead, a new browser window will be opened, and we will see how each step of the test is executed. This could be helpful in case we want to debug our tests.
- We open a new page in the browser, and we go to a specific URL. In this case, the Auth0 homepage.
- We hover some elements to display different menus. We also click on links to go to other pages. `HoverAsync` and `ClickAsync` accept [CSS selectors](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors) to look for specific elements in the web page.
- We can also type text inside an input with `TypeAsync`.
- With `EvalOnSelectorAsync`, we execute an expression and get its result. In this case, we look for the `href` property value of an `<a>` element with the specified CSS selector. We compare that value with the URL we expect, so we can say the test passed correctly.

If we run the test, it should pass (if the Auth0 page didn't change since this article was written).

![Successful Test](https://images.ctfassets.net/23aumh6u8s0i/8IlLz1hcJmRQRkMtRJX2z/d2b1104b3c134af53b4ecd19fdb5b44e/playwright-successful-test.png)

## What's Next?

We created a simple end-to-end test, so we saw how to use some of Playwright Sharp main features. If we want to create more complex UI tests or to automate another kind of browser-based task, we can take a look at the [Playwright GitHub repository](https://github.com/microsoft/playwright-sharp) for some examples. We also have the [official Playwright documentation site](https://playwright.dev/docs/intro), where we can read about different concepts and functions we have available to create our automation processes. There are various elements from a web page that we can interact with: dialogs, downloads, authentication, videos, etc. We can also generate screenshots of what's displayed in the browser or even generate PDF files.

## Summary

In this article, we talked about UI testing and how to implement that through browser automation using Playwright Sharp. If we want to create tests that cover the possible workflows of our web application and analyze the visual elements of them, a library like Playwright Sharp is a powerful tool. With it, we can create end-to-end tests supporting all modern web browsers.

<include src="asides/DotNetCore" />

End-To-End Testing With Playwright Sharp

joyce-echessa

Guest Author

Joyce Echessa

Learn how to process images using the Pillow Python library.

Image Processing in Python with Pillow

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Add these cybersecurity books to your library and develop the skills that will support your career.

30 Cybersecurity Books To Deepen Your Knowledge

30b8d1b7c0dab4bb311c121a47a6aae9?s=80 avatar

30b8d1b7c0dab4bb311c121a47a6aae9?s=80

Vladimir Fomene

This article demonstrates how you can use Project Lombok library to avoid boilerplate code from your Java projects.

Avoiding Java Boilerplate Code with Project Lombok

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Dan Arias

Learn how to build a component library with Vue and Storybook to create modular and reusable components.

Using Storybook with VueJS

Learn how to build a component library with React and Storybook to create modular and reusable components that can be shared across projects.



Storybook is a development environment for UI components. It let us browse a component library, view the different states of its components, and interactively develop and test them. Storybook runs outside of our application; therefore, we can develop UI components in isolation without worrying about any project dependencies and requirements.

For the scope of this introductory blog post, we are going to demonstrate how to start a new project using Storybook to get familiar with its platform and mechanics stemming from the "Storybook-Driven Development" practices that we have [developed at Auth0 within the Customer Success Infrastructure team](https://auth0.com/blog/our-engineering-experience-with-react-and-storybook/).

In a previous blog post, we created the [foundation of our project by setting up a component library](https://auth0.com/blog/setting-up-a-component-library-with-react-and-storybook/). If you have been following along you may continue to build upon where we left. Otherwise, feel free to clone the [Marvel Bank app repo](https://github.com/auth0-blog/marvel-bank-app) and checkout the `A-Tale-of-Reusability-Part-1` branch which includes all the work that we've done in the first part.

```shell
git clone https://github.com/auth0-blog/marvel-bank-app.git
cd marvel-bank-app/
git checkout A-Tale-of-Reusability-Part-1
```

Let's start by learning how we can setup Storybook in a brand-new `create-react-app` project.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Thrilling news: the next chapter for <a href="https://twitter.com/storybookjs?ref_src=twsrc%5Etfw">@storybookjs</a> with full-time maintenance and a bigger team. I&#39;m over the moon!<a href="https://t.co/xWL3Gp5dzI">https://t.co/xWL3Gp5dzI</a> <a href="https://t.co/T1JJfzNGp6">pic.twitter.com/T1JJfzNGp6</a></p>&mdash; shilman (@mshilman) <a href="https://twitter.com/mshilman/status/1021411688749326338?ref_src=twsrc%5Etfw">July 23, 2018</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

## Setting Up Storybook

There are two options available to us for adding Storybook: we can install the platform globally or we can start the platform locally. Which installation path should we take?

Our colleague, Matt Machuga, an Engineering Lead in our R&D Team, suggests that "CLI tools that are not project specific are good candidates for global installation." In practice, Matt tries to "scope everything else into local. So the version being used is kept recorded and installed via `npm install`."

We have different options for installing Storybook: a global install, an install using `npx`, and a local manual install. I'll explore those options with you and let you decide which one is right for you. However, I do recommend that you walk with me through the local manual install as it let us learn a great deal about how Storybook works.

### Install `@storybook/react` Globally

To install and run Storybook from your shell follow these quick steps:

- In the shell, make sure that your project directory your current working directory, `marvel-app`.

- Next, install `@storybook/cli` globally:

```shell
npm i -g @storybook/cli
```

> Above, we used a few `npm` argument shortcuts. `i` stands for `install` and `-g` stands for the flag `--global`.

- Restart your shell. You can do that by closing the existing window or tab and opening a new one.

- Finally, with `marvel-app` again as your current working directory, run the `getstorybook` command to have the Storybook CLI scaffold all the necessary files and folders to work with Storybook in your project. These include the `.storybook` folder under the root project and the `stories` folder under the `src` folder.

Let's see how this can be done without a global install using `npx`.

### Install `@storybook/react` Using `npx`

We can emulate the same behavior of the global installation of Storybook but without the actual global installation. If you have `npm >= 5.2` installed in your system, you have `npx` available!

- In the shell, make sure that your project directory your current working directory, `marvel-app`.

- Run the `getstorybook` command using `npx`:

```shell
npx @storybook/cli getstorybook
```

[`npx` downloads and executes the binary on the fly](https://alligator.io/workflow/npx/). The Storybook CLI will run and create all the necessary files and folder in your project just as in the previous section. This method is the fastest way to get up and running!

<include src="TweetQuote" quoteText="npx lets us run one-off invocations of CLI tools available in the npm registry without local installation."/>

Now, let's explore what the Storybook creators call the "slow start", the local manual installation of Storybook. Through that process, we'll learn how the folders and files installed by the Storybook CLI work.

### Install @storybook/react manually

In the shell, let's run the following command:

npm:

```shell
npm i -D @storybook/react
```

> Another `npm` argument shortcut. `-D` stands for `--save-dev`.

### Storybook NPM Script

After `@storybook/react` has finished its installation. We need to add the following `script` to `package.json` to run Storybook:

```json
"storybook": "start-storybook -p 9001 -c .storybook"
```

```json
{
  "name": "marvel-bank",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "node-sass-chokidar": "^1.3.3",
    "npm-run-all": "^4.1.3",
    "react": "^16.4.1",
    "react-dom": "^16.4.1",
    "react-scripts": "1.1.4"
  },
  "scripts": {
    "build-css": "node-sass-chokidar src/ -o src/",
    "watch-css":
      "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",
    "storybook": "start-storybook -p 9001 -c .storybook",
    "start-react": "react-scripts start",
    "start": "npm-run-all -p watch-css start-react",
    "build-react": "react-scripts build",
    "build": "npm-run-all -s build-css build-react",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "devDependencies": {
    "@storybook/react": "^3.4.8"
  }
}
```

### Create A Storybook Configuration File

[As explained in the Storybook docs](https://storybook.js.org/basics/guide-react/), the platform is flexible and can be configured in different ways. We can control that configuration through a config directory. In our `storybook` `npm` script, we added a `-c` option followed by `.storybook` which tells Storybook to look for configuration options in the `.storybook` hidden folder.

Having our project root folder as the current working directory, let's go ahead and create that folder:

macOS/Linux/Windows:

```shell
mkdir .storybook
```

Next, we need to create a `config.js` file inside `.storybook` to hold the configuration. Let's start it with the following code:

```javascript
// .storybook/config.js

import { configure } from "@storybook/react";

function loadStories() {
  require("../src/stories/index.js");
  // You can require as many stories as you need.
}

configure(loadStories, module);
```

Storybook works in a similar way to testing tools. The `config.js` loads the `configure` method, which takes as argument a function called `loadStories` and a `module`. `loadStories` will have **stories** defined on its body. A **story** describes the single state of a component. We want to write a story for each state a component will have.

> Stories are similar to how [`it` methods run tests](https://jestjs.io/docs/en/api.html#testname-fn-timeout) in testing libraries like Jest.

We are going to write and load the stories from `../src/stories/index.js` which will be under the root folder. Let's create such folder and file to write our first story. Under the `src` folder let's create a `stories` subfolder and then create an `index.js` file inside it.

> `.storybook` is used solely for configuration files. Do not put your `stories` folder inside this hidden folder.

### Writing a Story in Storybook

Open the recently created `index.js` under `src/stories` and populate it with the following code:

```javascript
// src/stories/index.js

import React from "react";
import { storiesOf } from "@storybook/react";
```

So far, there's not much going on. We import `React` and a `storiesOf` method that will help us create stories for a component. We need that component. Let's import `Button` here:

```javascript
// src/stories/index.js

import React from "react";
import { storiesOf } from "@storybook/react";
import Button from "../../src/features/common/Button";
```

Storybook has a declarative language. What we are going to do next is to tell it that we want stories of `Button`:

```javascript
// src/stories/index.js

import React from "react";
import { storiesOf } from "@storybook/react";
import Button from "../../src/features/common/Button";

storiesOf("Button", module);
```

If we were thinking in terms of an actual book, this is the book's binding and cover. We need to fill it with pages full of stories. We do that declarative too using the `add` method:

```javascript
// src/stories/index.js

import React from "react";
import { storiesOf } from "@storybook/react";
import Button from "../../src/features/common/Button";

storiesOf("Button", module).add("with text", () => (
  <Button label={`Continue`} />
));
```

`add` acts like adding a chapter to a book that has a story. We want to give each chapter a title. In this case, we are creating a story titled `with text`. `add` takes as argument the story title and a function that renders the component being staged.

We have the foundation of writing a story. It's time to see if everything is working by running Storybook.

<include src="TweetQuote" quoteText="Similar to testing, Storybook uses declarative language to let us write stories that define the expected presentation and behavior of our components."/>

### Running Storybook

In the shell, run the following command:

npm:

```shell
npm run storybook
```

If everything runs successfully, we will see this message in the shell:

```shell
info Storybook started on => http://localhost:9001/
```

Let's open that URL, [`http://localhost:9001/`](http://localhost:9001/) in the browser. Let it load... and there we have it in its full glory: our own Storybook!

Right now it's pretty basic but this is a great start!

![A working Storybook](https://images.ctfassets.net/23aumh6u8s0i/3UAjbi2EhTJSdzs2kZ11UB/3d29231861b685150289a990396fe2f7/first-storybook)

This is a good time to make another commit to address the integration of Storybook:

```shell
git status
git add .
git commit -m "Integrate Storybook"
```

## Integrating CSS with Storybook

To communicate the presentation and state of the `Button` component, we need to add styling to it. Under `src/features/common`, let's create `Button.scss` and populate it with the following code:

```scss
// src/features/common/Button.scss

@import "../../styles/theme";

.Button {
  display: flex;
  flex-direction: row;
  justify-content: center;
  align-items: center;

  height: 40px;
  width: 160px;
  border: 2px solid $blue;
  border-radius: 60px;

  font-family: $primary-font;
  font-size: 16px;
  color: $blue;
  letter-spacing: 1.27px;
  text-align: center;

  text-transform: uppercase;
}
```

Next, let's import that stylesheet into `Button.js` and add `Button` as a `className` for the `Button` component:

```javascript
import React from "react";

import "./Button.css";

const Button = props => <div className="Button">{props.label}</div>;

export default Button;
```

Let's save our work. We should see now how Storybook has refreshed the board and shows the updated component with styling applied:

![Storybook staged a component with styling applied.](https://images.ctfassets.net/23aumh6u8s0i/1AvF1A0X8rNWYpCg5IP8YE/02e3f25e86dc8b04bb1fdc50a6eec788/storybook-with-component-with-style)

Just like with `create-react-app`, we can make changes to the structure, content, or style of a component and they will be updated in Storybook. Let's change the background, font color and border of `Button` to see this in action:

```scss
// src/features/common/Button.scss

@import "../../styles/theme";

.Button {
  display: flex;
  flex-direction: row;
  justify-content: center;
  align-items: center;

  background: $green;

  height: 40px;
  width: 160px;

  border-radius: 60px;

  font-family: $primary-font;
  font-size: 16px;
  color: white;
  letter-spacing: 1.27px;
  text-align: center;

  text-transform: uppercase;
}
```

Let's save our work again and observe the changes:

![Updated component in Storybook](https://images.ctfassets.net/23aumh6u8s0i/6wpOxGNqq4MFoJOklUpsFq/dedd7dc955550d85196c93ac54114c53/component-updated-in-storybook)

Style changes are well integrated into our workflow. It's truly amazing that we can preview our components this way without having to run our application. We can develop our component in isolation and then use them in the app whenever we want.

<include src="TweetQuote" quoteText="Just like with `create-react-app`, we can make changes to the structure, content, or style of a React component and it will be updated in Storybook! We can visualize our components without running our app."/>

As discussed before, `Button` has three different presentations. The best way to organize that would be through CSS classes and props.

We want the `Button` component to know:

- Its active state: `active` / `disabled`
- Its style state: `fill` / `no-fill`

Let's update `Button.scss` with classes that represent these states:

```scss
// src/features/common/Button.scss

@import "../../styles/theme";

.Button {
  display: flex;
  flex-direction: row;
  justify-content: center;
  align-items: center;

  height: 40px;
  width: 160px;

  border-radius: 60px;

  font-family: $primary-font;
  font-size: 16px;

  letter-spacing: 1.27px;
  text-align: center;

  text-transform: uppercase;
}

.active {
}

.disabled {
  border: 2px solid $color-text-lighter;

  color: $color-text-lighter;
  letter-spacing: 1.64px;
}

.fill {
  background: $green;
  box-shadow: 0 6px 8px 0 rgba(103, 194, 172, 0.5);

  color: $white;
  letter-spacing: 1.61px;
}

.no-fill {
  border: 2px solid $blue;

  color: $blue;
  letter-spacing: 1.27px;
}
```

Let's briefly review what we are doing here since it's important how this impacts component staging in Storybook:

- `.Button` has all the style properties shared by all instances of `Button`.
- `.active` is not in use right now but it could be used to provide unique properties to an active button.
- `.disabled` has the style properties for any instance of `Button` that becomes disabled.
- `fill` and `no-fill` apply distinct styling to an active button.

We need to integrate this style logic into our component logic as follows:

```javascript
// src/features/common/Button.js

import React from "react";

import "./Button.css";

const Button = props => (
  <div
    className={`Button ${
      props.active
        ? props.fill
          ? `active fill`
          : `active no-fill`
        : `disabled`
    }`}
  >
    {props.label}
  </div>
);

export default Button;
```

Using a combination of ternary operators we process the state of the button. If `props.active` is true, we check if `props.fill` is true or not and apply the corresponding class to the component. If `props.active` is false, there are no extra decisions to make and we apply the default `disabled` class.

To see this in action, let's create new stories in our Storybook!

## Creating Multiple Stories for a Component in Storybook

Let's head to `src/stories/index.js` and remove the current story that we have defined there, `with text`, as it isn't telling too much of a story:

```javascript
// stories/index.js

import React from "react";
import { storiesOf } from "@storybook/react";
import Button from "../../src/features/common/Button";

storiesOf("Button", module);
```

Next, let's add three new stories that clearly define the three presentations that we want `Button` to have depending on different state flags:

```javascript
// stories/index.js

import React from "react";
import { storiesOf } from "@storybook/react";
import Button from "../../src/features/common/Button";

storiesOf("Button", module)
  .add("active with fill", () => (
    <Button label={`continue`} fill={true} active={true} />
  ))
  .add("active with no fill", () => (
    <Button label={`sign up`} fill={false} active={true} />
  ))
  .add("disabled", () => <Button label={`continue`} active={false} />);
```

Let's save our work and we'll see Storybook update to show the three new stories under `Button`:

![Storybook showing three stories for a component](https://images.ctfassets.net/23aumh6u8s0i/5mnvrrwKAOaFwGotkdighn/e3b99cf5b9806db3cbc9a9b3e864b0c8/storybook-component-with-three-stories)

Each story renders an isolated instance of `Button` whose presentation depends on the `props` values that are passed to it. This is where we can see the value proposition of Storybook at play.

Without Storybook, we would need to add `Button` in our app somewhere and test its rendering by passing it different props. We would then need to remove the component. What if we need to change the structure or style of the component? We'd need to start that process all over again.

With Storybook, a component and all of its different states can be staged in a centralized location. What we see in Storybook will be seen in all the areas of the application that use the component, giving us confidence that we'll have presentational consistency throughout our application.

Let's click around the different stories and see how the component changes on each one. The UI Kit graphic definition of the user interface button is now alive in code.

"Button active with fill":

![Button active with fill](https://images.ctfassets.net/23aumh6u8s0i/67vqM3hxatu2OndYfYML5M/4feee7076faa1f382625e60a93a2b5d2/button-active-fill-state)

"Button active with no fill":

![Button active with no fill](https://images.ctfassets.net/23aumh6u8s0i/5CUP65tjJwCENcQxsUl2dH/d8edd5c0f1ab28d301cd1c97990898bd/button-active-no-fill)

"Button disabled":

![Button disabled](https://images.ctfassets.net/23aumh6u8s0i/1pNWNhqeyo8Dj2RpkLsYhl/cec1d9dd564a80c1f539e1f90c1c7812/button-disabled-view)

We have a solid `Button` component that communicates its state clearly through its presentation. Let's go ahead and commit these changes:

```shell
git status
git add .
git commit -m "Add three states to Button component"
```

### Next Steps

We have just barely scratched the surface of what can be done with Storybook! There's a lot more we can do with this amazing tool to make the creation, testing, and documentation of React components much faster. Storybook is also a highly configurable tool that relies on add-ons to boost its offerings.

At Auth0, different teams are making extensive use of Storybook in their React development and design processes. We are converging designers and developers into a Design Systems team that is letting us iterate faster and develop better products for our cherished customers.

Feel free to grab the source code of the project we have created so far from the [Marvel Bank App GitHub repo](https://github.com/auth0-blog/marvel-bank-app).

<include src="asides/AboutAuth0" />


Building a Component Library with React and Storybook

Learn how to set up a component library with React and Storybook to create modular and reusable components that can be shared across projects.



[Storybook](https://storybook.js.org/) is a development environment for UI components. It let us browse a component library, view the different states of its components, and interactively develop and test them. Storybook runs outside of our application; therefore, we can develop UI components in isolation without worrying about any project dependencies and requirements.

We've shared about [our experience using React and Storybook to better manage components](https://auth0.com/blog/our-engineering-experience-with-react-and-storybook/). In this post, we are going to explore how to organize a basic project, how to implement a style guide to help us achieve consistent branding, and how to build the foundation of a component library to make our components reusable and easy to maintain.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">React is such a good idea that we will spend the rest of the decade continuing to explore its implications and applications.</p>&mdash; Guillermo Rauch (@rauchg) <a href="https://twitter.com/rauchg/status/801005961334943744?ref_src=twsrc%5Etfw">November 22, 2016</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Let's start.

## Setting Up a React Project

We are going to use [`create-react-app`](https://github.com/facebook/create-react-app) to scaffold easily a new React application.

We can run `create-react-app` using `npx` which comes bundled with `npm 5.2+` and higher:

```shell
npx create-react-app marvel-bank
cd marvel-bank
```

If you use `npm 5.1` or earlier, you can't use `npx`. Instead, install `create-react-app` globally:

```shell
npm install -g create-react-app
```

And then run:

```shell
create-react-app marvel-bank
cd marvel-bank
```

> Notice that we are not running `npm start`. As mentioned earlier, we don't need to have a running React application to use Storybook.

Open the newly created `marvel-app` folder on your preferred code editor or IDE.

Within `marvel-bank`, the `src` folder contains the core business logic of our React application. Let's do some housekeeping and remove files and code that we don't need.

Open `src/App.js` and trim it like so:

```javascript
// src/App.js

import React, { Component } from "react";
import "./App.css";

class App extends Component {
  render() {
    return <div className="App" />;
  }
}

export default App;
```

Next, let's delete the following files:

- `App.test.js`
- `logo.svg`

> **Spoiler**: Storybook is an essential part of our testing stack as it makes testing a painless experience.

## Using a Style Guide for Consistent Branding

Using a style guide can lead to better application design and development. As explained by the [Marvel Design team](https://blog.marvelapp.com/style-guides-better-design-development/), "during the design phase style guides encourage consistency in the visual identity and help keep the interface system as logical as possible, which makes for a better UX."

What is a style guide anyway? Marvel has a solid answer: "A style guide clearly demonstrates how all interface elements and components are to be visually represented. It’s essentially a master reference for the user interface (UI)."

In this sense, a component library is part of a style guide as it presents our components visually and it is the single source of truth for each component (the master reference). To create a comprehensive style guide, the component library can be accompanied by design documents that define font styles and sizes as well as primary and secondary user interface colors. A Design Team usually creates a "UI Kit" that is handed to developers for implementation. _Shopify_ explains that a [UI kit is an assortment of graphic files](https://www.shopify.com/partners/blog/104547526-the-benefits-of-using-a-ui-kit) that include UI components (buttons, checkboxes, progress bars, etc.) for the purpose of defining and designing the user interface.

<include src="TweetQuote" quoteText="A component library helps you achieve consistent branding as it becomes the single source of truth for every component not only in the application but for all projects in the organization"/>

For the online banking app that we are going to start creating in this blog post, we are going to use a free Banking UI Kit that [Marvel created for Sketch](https://blog.marvelapp.com/free-banking-ui-kit-for-sketch/). To honor their effort, we named the app `marvel-bank`. The UI Kit looks as follows:

![Marvel Banking UI Kit](https://images.ctfassets.net/23aumh6u8s0i/5l9Xw1gUqAiHm7l7pEQXI1/4e372a21ee5778f75914ab05359a4d13/marvel-banking-ui-kit)

The UI Kit is designed for iOS, but we are going to adapt it for usage in a responsive web application. To make it easier for developers to understand the UI Kit, I created a design document where we can get the font names, the sizing, the color hex codes, etc: [Marvel Bank Style Guide](https://auth0.github.io/marvel-bank-styleguide/).

In the following excerpt, notice how is much easier to understand the guidelines that a developer would need to follow when creating the components presented in the UI Kit:

![Style guide design - typography and color palette](https://images.ctfassets.net/23aumh6u8s0i/1jmP0Jdc0o4Fb5VUnoNtgO/fe24cc9b198abb20e8403e4855b2621e/design-document)

If we need to implement a green button, we can consult the design document and copy the hex code of `$green`; however, it would be much easier if we could code the elements of the design document into our application in a modular way and reusable way. We have plenty of options to do that:

- We could use CSS variables, also known as [custom properties](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables).
- We could use [SCSS](https://sass-lang.com/), [LESS](http://lesscss.org/), or [Stylus](http://stylus-lang.com/) to create style partials and variables.
- We could also opt for using [CSS-in-JS](https://reactjs.org/docs/faq-styling.html) through a library like [`styled-components`](https://www.styled-components.com/).

Our Team currently has been using a combination of Stylus and [CSS Modules](https://github.com/css-modules/css-modules) to manage the styling of the projects. React has unified the three layers of front-end development (HTML, CSS, and JavaScript) under one layer powered by JavaScript, JSX, and CSS-in-JS. For this post, however, we are going to rely on SCSS to create the modular components to minimize the development overhead.

> **Feedback:** Would you like to learn how we are using `styled-components` to create a modern component library? Let us know in the comments below and we could create a blog post about it.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Oh man and a <a href="https://twitter.com/storybookjs?ref_src=twsrc%5Etfw">@storybookjs</a> shoutout as well! Storybook has been indispensable for our component library.</p>&mdash; Maja Wichrowska (@majapw) <a href="https://twitter.com/majapw/status/997143616865828865?ref_src=twsrc%5Etfw">May 17, 2018</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

## Adding SCSS to `create-react-app`

We can [add `SCSS` support to `create-react-app`](https://techcookbook.com/react/use-scss-with-create-react-app) without having to `eject` to a custom setup. We need to install a few packages to help us achieve that goal:

NPM:

```shell
npm install --save node-sass-chokidar npm-run-all
```

[`node-sass-chokidar`](https://www.npmjs.com/package/node-sass-chokidar) is a thin wrapper around the node-sass executable to use [chokidar](https://github.com/paulmillr/chokidar) instead of [Gaze](https://github.com/shama/gaze) when watching files.

[`npm-run-all`](https://www.npmjs.com/package/npm-run-all) is a CLI tool to run multiple npm-scripts in parallel or sequentially.

Next, we need to modify our `package.json` `"scripts"` property to watch and process `.scss` files into `.css` ones:

```json
{
  "name": "marvel-bank",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "node-sass-chokidar": "^1.3.3",
    "npm-run-all": "^4.1.3",
    "react": "^16.4.1",
    "react-dom": "^16.4.1",
    "react-scripts": "1.1.4"
  },
  "scripts": {
    "build-css": "node-sass-chokidar src/ -o src/",
    "watch-css":
      "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",
    "start-react": "react-scripts start",
    "start": "npm-run-all -p watch-css start-react",
    "build-react": "react-scripts build",
    "build": "npm-run-all -s build-css build-react",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  }
}
```

These scripts allow us to compile `.scss` files into `.css` and to keep watching the `src` folder for changes to the content of existing `.scss` files or the addition of new ones. To complete this task, we need to change the file extension of `App.css` and `index.css` to `.scss`. Depending on our development environment, this can be done in different ways such as renaming the files or refactoring their name or file type.

Storybook will only understand changes made or applied in `.css` files. If we were to make a change in a `.scss` file, we would need to compile it into `.css` for Storybook to be notified of the styling changes.

Normally, such compilation is a build step in our development workflow triggered by running `npm start`. However, I made the promise that we wouldn't have to run our React app in order to use Storybook in this blog post. I am keeping that promise and `npm start` is off-limits. What can we use instead? `watch-css`.

As stated earlier, `watch-css` compiles our SCSS into CSS files using the `build-css` script and it keeps monitoring all the SCSS files present under the `src` directory to detect any changes. Anytime an SCSS file is changed, that file is compiled and Storybook is able to see and apply the styling changes into the component preview (as we'll see soon!).

With this in mind, on the shell run the following command:

```shell
npm run watch-css
```

This is a good point to make our first `git` commit.

## Using `git` Version Control

Our project is in a good place for its first `git` commit. But before we do so, let's ensure that we have everything we need to ignore specified in the `.gitignore` file. If you are using an IDE like WebStorm, for example, there are extra files that the IDE creates that is better to keep out of the `git` repo.

I personally like to use [`gitignore.io`](https://www.gitignore.io/) to generate the content of my `.gitignore` file automatically. The categories that I choose to create the file are WebStorm, IntelliJ, OSX, Windows, and Visual Studio Code, since they are the tools and platforms that are most commonly used. You may head to that site, enter those categories, and copy/paste the output at the end of the `.gitignore` file present in our project.

Since our `.css` files are built automatically under our project configuration, we do not need to include them in version control. In the `.gitignore` file add the following rule at the end:

```text
// .gitignore

// ...

src/**/*.css
```

This rule ensures that none of the `.css` files under the `src` folder are tracked by `git`.

With a comprehensive `.gitignore` file in place, let's initialize a `git` repository (make sure that `marvel-app` directory is the current working directory):

```shell
git init
```

Let's run a quick `git status` check to see what files are being untracked:

```shell
git status
```

Let's go ahead and add these files shown to `git` in order to include them in our commit:

```shell
git add .
```

We used a shortcut here to add all the files that were being untracked using the `.` after the `add` command.

> If you want a `git` refresher, I highly recommend this amazing [_Git & Version Control_](https://www.git-tower.com/learn/) tutorial by the folks at [Git Tower](https://www.git-tower.com/).

Running `git status` again would show us the new files that have been added that include changes to be committed. Let's create our first commit then:

```shell
git commit -m "Initial commit"
```

We'll get a reply by `git` showing all the files that were changed and the insertions that were made. Having a well-thought commit history in place will let us go back in time if we ever need to use an older version of our code. `CTRL/CMD + Z` can only go so far back!

This all looks good to me ([LGTM™](https://knowyourmeme.com/memes/lgtm)), but before we include any styling or components in our project, we need to create a sound file structure.

## Project Structure

An internal pattern that we use is to have specialized folders to hold the different elements of our React application. In one of our projects, we have the following structure:

```shell
- src
    |-- api/
    |-- features/
    |-- assets/
    |-- redux/
    |-- styles/
    |-- utils/
    |-- App.js
    |-- index.js
    |-- routes.js
```

For the initial phase of this project, we only need the `features` and the `styles` folder. The `features` folder holds our components in a categorized manner. We define features of our applications, such as `search` or `reports` in its subfolders, and create components that power and build that feature. What Storybook will help us solve is the event where features share components. Instead of duplicating the code across features, the feature will implement the component from a central source: our component library. As the name suggests, these common components go into a `common` feature folder.

This is the project structure we want for the `src` folder in this phase of the project:

```shell
- src
    |-- features/
    |---- common/
    |-- styles/
    |---- _theme.scss
    |-- App.js
    |-- App.scss
    |-- index.js
    |-- index.scss
    |-- registerServiceWorker.js
```

<include src="TweetQuote" quoteText="Instead of duplicating the component code across features in your project, implement the component from a central source, like a component library."/>

Let's go ahead and create these folders and files:

![Demo banking app file and code structure](https://images.ctfassets.net/23aumh6u8s0i/2dU4QkYNlJJVywa4N2tDLC/9a9ee8f4619c15548be4d0b9a7c1cdd8/file-structure)

We'll be using `_theme.scss` in a moment. This is a good checkpoint. Let's go ahead and commit:

```shell
git status
git add .
git commit -m "Create project structure that integrates with SCSS"
```

> Noticed something different this time? Since the `features` folder and its `common` subfolder are currently empty, they were not included as part of the commit bundle by git. We could place an `index.js` file inside `common` that exports all of the components within that folder using what is known as a [barrel export](https://medium.com/@klauskpm/do-a-barrel-export-aa5b79b76b05). For this blog post, we are not going to use that just yet.

## Creating the Application Theme

`_theme.scss` is an SCSS partial that will be imported by any other component stylesheet that needs to apply the defined theme based on the [Marvel Banking Style Guide](https://auth0.github.io/marvel-bank-styleguide/). You can copy and paste the following definitions to your local `_theme.scss` file:

```scss
// src/styles/_theme.scss

// Fonts
$primary-font: "Lato", sans-serif;
$secondary-font: "Open Sans", sans-serif;

// Font Colors
$color-text: #4f6c8d;
$color-text-light: #a3adb4;
$color-text-lighter: #ccd6e1;

$color-text-contrast: #ffffff;
$color-text-contrast-light: #a7b5c6;
$color-text-contrast-lighter: #5f5f63;

// Background Colors
$gray: #bec9d1;

// Primary Colors
$blue: #506e8d;
$white: #ffffff;
$green: #6bbfab;
$red: #f96b6b;

// Dark Primary Colors
$dark-blue: #33475c;
$dark-white: #f0f0f0;
$dark-green: #5ba392;
$dark-red: #de5e5e;

// Auxiliary Colors
$bright-blue: #5db8eb;
$opaque-blue: #4770d6;
$opaque-yellow: #f3c416;
$opaque-red: #dd765f;
```

Since this is a significant checkpoint, let's commit again:

```shell
git status
git add .
git commit -m "Create app theme variables"
```

It's time to start creating components!

## Creating A Reusable Button Using React

To see the benefits and value that Storybook provides us, we need to have components to visualize. Right now, we have none.

Recall that the Marvel UI Kit offers us the definition of a button that has three presentations:

![Styling UI buttons - Primary, secondary, tertiary - Active and Disabled state buttons](https://images.ctfassets.net/23aumh6u8s0i/6i3Qy1NxBCFUJaAwuXyTuj/31b7a71ce3de1fd752c0f908f8061fda/ui-button)

These presentations can be summarized as follows:

- Active State (Fill): The button is green, pops up, and has white text.
- Active State (No-Fill): The button shares the background of the parent container, and it has a blue color for its text and border.
- Disabled State: The button looks suppressed and has a light blue color for its text and border.

The button itself has two status: active or disabled. The relationship between presentation and state is something that we can express easily with Storybook. First, we need to plan the component. How are we going to approach its engineering?

Let's start with creating the basic structure of the component: a rounded rectangle that contains a label. Create a file named `Button.js` under the `common` folder and populate it with this:

```javascript
// src/features/common/Button.js

import React from "react";

const Button = props => <div>{props.label}</div>;

export default Button;
```

Let's quickly commit the creation of the `Button` component:

```shell
git status
git add .
git commit -m "Create Button component"
```

Now that we have a component, we go back to one of the questions that we have been asking ourselves in our team when creating components:

- How should a prototype of the component be presented? Should a blank page with mock data be used?

Traditionally, we would compose the component into a visible element of the UI to preview it. This time, we are going to use Storybook.

### Next Steps

We have built a foundation to help us create our online banking web app with consistent branding by implementing a style guide. At Auth0, different teams are making extensive use of Storybook as a development and design tool. We are converging designers and developers into a Design Systems team that is letting us iterate faster and develop better products for our cherished customers.

Feel free to grab the source code of the project we have created so far from the [Marvel Bank App GitHub repo](https://github.com/auth0-blog/marvel-bank-app). The repo is being built gradually and contains commits that cover the work we have done in this blog post and on future posts. To start from scratch, be sure to [create a branch from the first commit](https://stackoverflow.com/questions/2816715/branch-from-a-previous-commit-using-git): `Initial commit`.

For more content like this, follow [@auth0 on Twitter](https://twitter.com/auth0) or subscribe to our newsletter.

<include src="asides/AboutAuth0" />


Setting Up a Component Library with React and Storybook

Create modular and reusable components that can be shared across projects by building a component library with React and Storybook.



At Auth0, we want our customers to be successful using our [authentication solutions](https://auth0.com/b2c-customer-identity-management). The Customer Success Infrastructure Team builds customer-facing and internal tools that help us achieve that goal. One of the technologies that have enabled them to have rapid iterations in user interface development is [React](https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/).

[![Authenticate React using Auth0](https://images.ctfassets.net/23aumh6u8s0i/6I21NcoVBzBDHBnSxXfaZw/49c51ce5e8389783b607cd5312811480/react-auth0-banner)](https://auth0.com/authenticate/react/)

This team builds a variety of different projects such as the software that runs our [Auth0 Support Center](https://support.auth0.com/) and other internal tools that power internal support workflows. In addition to React, they develop their projects using [Node.js](https://nodejs.org/en/), [hapi.js](https://hapijs.com/), and [Redux](https://redux.js.org/). It is a JavaScript-heavy team and that is driven by building quality features quickly.

![Auth0 Customer Success Infrastructure Team](https://images.ctfassets.net/23aumh6u8s0i/1TZtO3xXdNrGdS2nshJank/3ab11dc08159450bbd3af27ae27d3785/auth0-customer-success-team)

> Would you like to be part of a Team like this? We are currently hiring engineers to [join the Customer Success Infrastructure team](https://auth0.com/careers/positions?areas=Customer%20Success)!

[Guillermo Rodas](https://twitter.com/glrodasz) is one of the Engineers of the Customer Success Infrastructure Team. He recently led a project initiative known as _Support Center Components_ that solved a problem centered around having duplicate React components in our customer-facing and internal tools site.

In this blog post, through Guillermo's insight, we are going to explore how the Account Center Team is using [React and Storybook](https://storybook.js.org/basics/guide-react/) to optimize UI development and promote consistent branding by creating a component library that can be shared across different projects.

## Don't Repeat Yourself (DRY)

[Auth0 Support Center](https://support.auth0.com/), a customer-facing site, and Customer Success Tools, an internal site, have similar elements on their interfaces. For example, despite having a different business context in each interface, the _Quota Utilization_ feature in both interfaces uses the same structure to report data to the user.

![Two identical React component defined in different codebases](https://images.ctfassets.net/23aumh6u8s0i/1lutGPjqyYNHccPBpXxf3z/ba96df5eb6edb898634676ced807c5ad/support-center-vs-cs-tools-component)

The problem that we had was that this structure was being implemented as a React component separately for each interface instead of sharing the implementation. The development team was duplicating components to solve the same problem. This approach inherently created pain points for developers as _Quota Utilization_ was just one of a few other features that had overlapping front-end architectures within our sites.

Having duplicate code is not ideal. One version of the code may be more up-to-date than another version, creating something similar to a race condition around code versioning. If a bug is found, it would need to be fixed in every place that shares the code while [hoping that the developer can remember them all](https://stackoverflow.com/a/2490897). An inconsistent bug fixing process could multiply bugs and create havoc in a codebase.

> "If you see patterns in your code, that is an [indication it is prime for DRYing](https://americanexpress.io/clean-code-dirty-code/). Sometimes this means standing back from the screen until you can’t read the text and literally looking for patterns." [(Donavon West, American Express Developer Relations)](https://twitter.com/donavon)

The solution for this code duplication problem was to make the code DRY (Don't Repeat Yourself). We needed to write the presentational component once and then have each feature/interface implement it from a single source of truth: a component library.

As explained by [Mark Perkins](https://twitter.com/allmarkedupa) from [Clearleft](https://clearleft.com/) on their insightful post [_On Building Component Libraries_](https://clearleft.com/posts/on-building-component-libraries), a component library is an effective and robust format for delivering documented code and design patterns to developers and clients. React lends itself to the architecting of a component library since it involves the process of thinking and building in a "componentised manner", as coined by Mark.

<include src="TweetQuote" quoteText='react lends itself to the architecting of a component library since it involves the process of thinking and building in a "componentised manner", as coined by @allmarkedup from @clearleft'/>

![Graphic of example web component library](https://images.ctfassets.net/23aumh6u8s0i/7b4rPdBjXGdnxv24ty2Vzc/7aa292937b5eb827ea725d4010561686/component-library)

[Source](https://blog.hichroma.com/beyond-bootstrap-moving-from-ui-toolkit-to-component-library-f0a34f05e98b)

## Integrating a Component Library

Implementing the concept of a component library within our workflow was an architectural decision that required us to further strategize our component and feature development process.

For example, when creating a component, we started asking the following questions:

- How to categorize the component within a library? Should we have categories at all?
- How should a prototype of the component be presented? Should a blank page with mock data be used?
- Should different states of the component be presented on its prototype?

It was critical to be able to answer these questions visually and in an organized manner to help us iterate cleanly through our feature development process. This process typically consists of:

- Creating an MVP (Minimum Viable Product) or POC (Proof of Concept).
- Getting feedback on the MVP/POC.
- Integrating feedback through development iterations.

Through that process, we are constantly showing how the user interface presents data through its components and defining the states of a component based on the data that it can present. We needed a tool that could let us:

- Create our components independent from any specific feature integration.
- Preview our components and their different states.
- Let us categorize each component into families for easier lookup.
- Host our components in a central location to create the concept of a library.

With React, we could already define components. We needed something to preview, categorize, and host them. Fortunately, we were able to fulfill all those requirements using one single tool: Storybook.

<include src="TweetQuote" quoteText="Don't reinvent the  &lt;Wheel /&gt;. To create modular and reusable components that can be shared across projects, build a component library with React and Storybook."/>

![Meme - I believe in code reuse... CTRL-C, CTRL-V](https://images.ctfassets.net/23aumh6u8s0i/2J67xmm28v3y1IGGkdHtmh/094c27a7ffdb0f2ff51d89c771ad3184/believe-in-code-reuse)

[Source](https://hermesespinola.wordpress.com/2016/11/24/code-reusability-dont-reinvent-the-wheel/)

## Storybook: Let Your Components Tell a Story

[Storybook](https://storybook.js.org/) is a UI development environment for UI components. It acts as a board where we can stage our components and visualize them in different states and interact with them as if they were on a live application. This is all done in isolation since Storybook runs outside of our app. Storybook has its own Webpack setup that is very similar to the one from `create-react-app` but can be configured to meet our needs. The platform also comes with a built-in dev server to help us preview our components locally.

![React Storybook component preview](https://images.ctfassets.net/23aumh6u8s0i/7aBehDlHBJczkWVH02PVSd/1449412c3d8c1e9ddc70e599c539c864/storybook-demo)

As we have described, we already had a working project when we decided to use Storybook to create a component library. However, because of its independent architecture, adding Storybook to our existing project did not create any burden or changes to our existing codebase.

We added it like any other `npm` package and then imported our existing components into its platform. However, it did require us to think differently about the creation, maintenance, and sustainment of our components moving forward &mdash; an integrative process we call "storybook-driven development."

With Storybook, we have been able to build our React components gradually in isolation without having to worry about having the final component version or environment ready from the start. It has doubled as a staging and planning tool for us.

<include src="TweetQuote" quoteText="Storybook and React let us plan, stage, and build components gradually. It's a living style guide."/>

## Documenting and Testing Pain Points

Our Customer Success Infrastructure team had a second problem: documenting and testing all the different scenarios of each project feature. In our projects, we have tests with high coverage that are run through a [continuous integration pipeline configured in Heroku](https://devcenter.heroku.com/articles/heroku-ci).

In Guillermo's words:

> "We have strong tests along with continuous integration because we want to have nice weekends without worrying about our production builds failing. The most common phrase in a [Pull Request (PR)](https://help.github.com/articles/about-pull-requests/) is: Please add the tests."

Aside from testing, we place high value in documenting code. It's our legacy for anyone who will be working with our codebase in the future. Fortunately, having a component library like Storybook allows us to document components visually and declaratively. Storybook provides a developer with all the information needed to understand the structure and state of a component.

Testing is hard. For most developers, testing is a sad story. Well, not anymore! With modern and powerful tools, our testing story is a happy one.

In React, there are different aspects of UI Testing. We categorize them as follows along with their tooling:

- Structural Testing:
  - [Enzyme](https://github.com/airbnb/enzyme)
  - [Jest Snapshot Testing](https://jestjs.io/docs/en/snapshot-testing)
- Interaction Testing:
  - Enzyme
- CSS/Styles Testing:
  - Image comparison to do regression testing
  - Jest Snapshot using inline styles
  - Other tools like [BackstopJS](https://garris.github.io/BackstopJS/), [PhantomCSS](https://github.com/HuddleEng/PhantomCSS), [Gemini](https://gemini-testing.github.io/), and [Happo](https://github.com/Galooshi/happo)
- Manual Testing

Storybook integrates with Jest Snapshot through an add-on called [`StoryShots`](https://github.com/storybooks/storybook/tree/master/addons/storyshots/storyshots-core). `StoryShots` adds automatic Jest Snapshot Testing to our codebase by using our existing Storybook stories as the input for Jest Snapshot Testing.

With our Heroku CI pipeline configured, each time someone makes a PR with a new component against our Storybook, this automated testing is triggered and a visual preview of our app is created. This lets us perform structural and style testing much faster.

## Sharing our Engineering Knowledge

We are happy to share what our engineering process looks like in detail and how it has positively impacted our developer experience in creating, testing, and documenting user interfaces.

You may stay in touch with us by following [@auth0 on Twitter](https://twitter.com/auth0), subscribing to our newsletter, or checking this blog back from time to time. We hope that you'll love the content that we are creating.

<include src="asides/AboutAuth0" />


Our Engineering Experience with React and Storybook

fikayo-adepoju

Fikayo Adepoju is a Full-stack developer, technical writer and tech content creator proficient in Web and Mobile technologies and DevOps with over 10 years experience developing scalable distributed applications. With over 40 articles written for CircleCI, Twilio, Auth0 and The New Stack blogs and also on his personal Medium page, he loves to share his knowledge to as many developers as would benefit from it. You can also check out his video courses on <a href="https://www.udemy.com/user/fikayo-adepoju/">Udemy</a>.

Full-Stack Developer

Fikayo Adepoju

Learn how to create virtual reality experiences on the web using the Threejs WebGL library and the WebVR UI library.

Getting Started with the New WebVR API

1097492785caf9ffeebffeb624202d8f?s=200 avatar

1097492785caf9ffeebffeb624202d8f?s=200

Prosper is a great speaker, community leader, open source hacker, technical consultant, and a fervent Developer Advocate. He is a full-stack software engineer who has worked on biometric, health and developer tools. Prosper recently co-founded a startup called Eden that’s focused on improving the quality of lives in Nigeria and currently leads the engineering team. He also co-founded forloop, the largest developer community in Africa.

Former Auth0 Employee

Prosper Otemuyiwa

ReactJS 16 brings major changes to the popular JavaScript library for building user interfaces. Learn what's new in ReactJS!



---

**TL;DR:** ReactJS is a UI library that has gained massive adoption by developers and organizations around the world because of its efficient and reactive model. In this article, we'll highlight notable additions to ReactJS 16 and dabble into the architecture it runs on.

---

ReactJS is a JavaScript library, built and maintained by Facebook. At the time of writing, ReactJS has over 78,000 stars on [GitHub](https://github.com/facebook/react). And many web platforms such as _Twitter_, _Airbnb_, _Lyft_, _Dropbox_, _Pinterest_, _Whatsapp_ and _Instagram_ use ReactJS to build their user interfaces. The ReactJS developer community is very robust. In fact, the community is so robust that when Facebook decided to implement the [BSD+ Patents license](https://code.facebook.com/posts/112130496157735/explaining-react-s-license/), there was a public outcry from the community. The complaints from developers were on every other blog and forum as well as at meetups and conferences. Developers and software shops around the world are pretty excited and relieved that ReactJS has been re-licensed under the **MIT** license.

ReactJS 16 was announced to the world on September 26, 2017. Facebook has been working on releasing this new version for a while now. It's great that there is a new release, but ReactJS 16 is a very special release. What's exciting about this new ReactJS release is the fact that it was entirely rewritten from scratch while ensuring that the public API remains unchanged. This major release brings a lot of new features, deprecations, and changes.

## ReactJS API-Compatible Rewrite - Why?

Questions have been flying around as to why Facebook decided to rewrite the internals of ReactJS while keeping the public API essentially unchanged. Facebook has been working on **React Fiber**, which is a reimplementation of ReactJS's core algorithm for about two years now. The goal of _React Fiber_ is to enable **incremental rendering**—the ability to split rendering work into chunks and spread it out over multiple frames. In addition, the ability to pause, abort, or reuse work as new updates come in and the ability to assign priority to different types of updates. There are many reasons as to why it was rewritten but I'll highlight a few reasons.

<include src="TweetQuote" quoteText="The goal of React Fiber is to enable incremental rendering."/>

1. ReactJS needed a way to support asynchronous rendering. The current architecture couldn't have handled this addition so it needed to be re-designed from the ground up.

2. Support for graceful and efficient error handling using error boundaries in ReactJS. It was difficult to add this frequently-demanded feature to the previously existing ReactJS architecture, so it needed to be re-designed from the ground up.

3. The need for a new foundation that is immensely extensible and powerful enough to accommodate new idea implementation going forward. Furthermore, the support for longstanding features such as having fragments, returning text from _render_, unification of the scheduling of different subtrees and simple, non-complex ways to write custom renderers for ReactJS.

## React Fiber

Let's talk a bit about **React Fiber**. As I mentioned earlier, React Fiber has been in development for a while. And there was a website made specially just to track the progress of React Fiber; [isfiberreadyyet.com](http://isfiberreadyyet.com).

_React Fiber_ is a complete, backward compatible rewrite of the ReactJS core which enables sophisticated scheduling of rendering work. It is a reimplementation of ReactJS's core algorithm. The goal of React Fiber is to increase its suitability for app development in sections like gestures, animation, and layouts. One key feature is the support for **incremental rendering**. _Incremental rendering_ is the ability to split the rendering process into chunks and spread it out over multiple frames.

_React Fiber_ is a reimplementation of a stack frame specialized for ReactJS components. Each fiber can be thought of as a virtual stack frame where information from the frame is preserved in memory on the heap, and because the info is saved on the heap, you can control and play with the data structures and process the relevant information as needed.

_React Fiber_ allows smooth rendering of the UI by pausing once in a while and checking for more important updates rather than waiting for all the changes to be propagated throughout the entirety of the component tree before updating the UI. The task scheduling ability of _React Fiber_ makes this possible.

In ReactJS, we have two important players: the **Reconciler** and the **Renderer**. The **Renderer** is a pluggable section of ReactJS that allows rendering of the UI to happen across and outside the DOM. It was originally created for the DOM but was later adapted to support native platforms. ReactJS has the _[ReactJS DOM Renderer](https://github.com/facebook/react/tree/master/packages/react-dom) - renders ReactJS components to the DOM_, _[ReactJS Native Renderer](https://github.com/facebook/react/tree/master/packages/react-native-renderer) - renders ReactJS components to native views_, and the _[ReactJS Test Renderer](https://github.com/facebook/react/tree/master/packages/react-test-renderer) - renders ReactJS components to JSON trees_.

The **Reconciler** is used by the renderer to perform updates to the DOM. Whenever a component updates, be it _mounting_, _unmounting_ or any form of update, the reconciler (_known as the stack reconciler_) processes the component tree from top to bottom synchronously in a single pass, checks for changes in the tree, then passes on these changes to the renderer. In previous versions of ReactJS, the reconciler did not have the ability to pause work, thus making performance suboptimal when deep updates occur and the CPU time is limited.

<include src="TweetQuote" quoteText=" In ReactJS, we have two important players: the Reconciler and the Renderer."/>

With React Fiber, the new reconciler has the ability to do the following:

* Split interruptible work into chunks.
* Pause work and come back to it later.
* Reuse previously completed work.
* And abort work.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">The Fiber Triangle demo now lets you toggle time-slicing on and off. Makes it much easier to see the effect. Thanks <a href="https://twitter.com/giamir?ref_src=twsrc%5Etfw">@giamir</a> for the PR! 🎉 <a href="https://t.co/qhsWUIyXPf">pic.twitter.com/qhsWUIyXPf</a></p>&mdash; Andrew Clark (@acdlite) <a href="https://twitter.com/acdlite/status/846456239693344769?ref_src=twsrc%5Etfw">March 27, 2017</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

> **Note:** Work is the result of an update. Updates are computations performed during the traversal of the component trees.

Check out more information on [Reconciliation](https://reactjs.org/docs/reconciliation.html) and the [React Fiber Architecture](https://github.com/acdlite/react-fiber-architecture).

## ReactJS 16 Features

Apart from the fact that ReactJS 16 runs on the new engine, _React Fiber_, ReactJS 16 ships with some new features.

* **Error handling using Error boundaries**: In ReactJS 16, the error handling has been greatly improved. Before now, ReactJS applications broke whenever a runtime error occurred and required a page refresh to recover from the broken state. The component is unmounted each time any error throw in the constructor, render method and lifecycle methods. In ReactJS 16, error boundaries have been introduced to capture errors and display a fallback UI instead of unmounting the component every time. **Error boundaries** are simply ReactJS components that catch JavaScript errors anywhere in a component and child trees, log those errors and display a fallback UI. It is important to know that error boundaries catch errors thrown in the constructor, render and lifecycle methods. The new lifecycle hook method that makes a class component an error boundary is `componentDidCatch(error, info)`. This method works like a try/catch block for components. Create an error boundary component once and call it everywhere it's needed in your application.

    ```js
    class ErrorBoundary extends React.Component {
      constructor(props) {
        super(props);
        this.state = { hasError: false };
      }

      componentDidCatch(error, info) {
        // Display fallback UI
        this.setState({ hasError: true });
        // You can also log the error to an error reporting service
        logErrorToMyService(error, info);
      }

      render() {
        if (this.state.hasError) {
          // You can render any custom fallback UI
          return <h1>Something went wrong.</h1>;
        }
        return this.props.children;
      }
    }
    ```

* **Support for Defining Custom DOM Attributes**: Before now, if you used a custom DOM attribute, ReactJS would skip it. In ReactJS 16, unknown attributes will be passed onto the DOM. A typical example is shown below:

    ```
    <div alien="skullIsland" />

    // will be displayed in ReactJS 15 as:
    <div />
    ```

    ```js
    <div alien="skullIsland" />

    // will be displayed in ReactJS 16 as:
    <div alien="skullIsland" />
    ```

**Note:** Using the canonical ReactJS naming for known attributes still remain the same.

* **Fragments and Strings as new render return types**: In ReactJS 16, you can now return an array of multiple elements from a component's render method.

    ```js
    render() {
      // No need to wrap items in an extra element!
      return [
        // Don't forget the keys :)
        <p key="first">ReactJS</li>,
        <span key="second">PreactJS</li>,
        <span> key="third">VueJS</li>
      ];
    }
    ```
    _Returning arrays_

    ```js
    render() {
      return 'Boss, I just returned a string. Can you believe it? ReactJS 16  is dope!';
    }
    ```
    _Returning a string_

* **Portals**: This is a concept allows you to render children into a DOM node that exists outside of the hierarchy of the parent component. In layman terms, it simply means a child can be inserted into a different location in the DOM via Portals. For example, your app has a section component with a paragraph element as its child. Portals can be used to make the paragraph child element break out of its container.

    ```js
      ReactDOM.createPortal(child, container);
    ```
    _Render the child into the container DOM node_

    ```js
    render() {
      return ReactDOM.createPortal(
        this.props.children,
        domNode,
      );
    }
    ```
    _A typical example_

* **Improved server-side rendering**: The server renderer was completely rewritten in ReactJS 16 to be very fast. In addition, server-side rendering in ReactJS 16 is about three times faster than ReactJS 15 because the server renderer supports _streaming_. This makes sending of data from the server to the client faster than usual. In ReactJS 16, there are two different methods for rendering on the client side, `render()` and `hydrate()`. `render()` as we already know for rendering content solely on the client side, `hydrate()` for rendering on top of server-side rendered markup. Furthermore, ReactJS 16 is better at hydrating server-rendered HTML once it reaches the client. It no longer requires the initial render to exactly match the result from the server. Instead, it will attempt to reuse as much of the existing DOM as possible.

<include src="TweetQuote" quoteText="In ReactJS 16, there are two different methods for rendering on the client side, render() and hydrate()."/>

    ```js
      import { hydrate } from "react-dom"
      import Profile from "./Profile"
      hydrate(<Profile />, document.getElementById("profile-container"));
    ```

> **Note:** `render()` can still be used to render on top of server-side rendered markup, but it's recommended to use `hydrate()` now for that type of rendering in ReactJS 16.


![ReactJS 16 vs ReactJS 15 server-side rendering](https://images.ctfassets.net/23aumh6u8s0i/7AbShTl9bxeoh6Kt57t6B1/31269d1949279d631e7a136f2583d656/1_E5Pmh6HSeybcF7C686B9pA)
_Source: hackernoon.com_

ReactJS 16 does not support error boundaries and portals in server-side rendering.

For more information, check out this [excellent article on server-side rendering in ReactJS 16.](https://hackernoon.com/whats-new-with-server-side-rendering-in-react-16-9b0d78585d67)

## ReactJS 16 Deprecations and Breaking Changes

There a few deprecations and a number of breaking changes in ReactJS 16.

* Discontinued support for React Add-ons.
* Calling `setState` with null no longer triggers an update.
* Calling `setState` directly inside the `render()` method always causes an update.
* `setState` callbacks now fire immediately after `componentDidMount` or `componentDidUpdate`.
* The `componentDidUpdate` lifecycle no longer accepts the `prevContext` parameter.
* `ReactDOM.render()` and `ReactDOM.unstable_renderIntoContainer()` now return `null` if called from inside a lifecycle method.
* Previously, changing the ref to a component would always detach the ref before that component's render was called. Now, we change the ref later, when applying the changes to the DOM.
* As I mentioned earlier, hydrating a server-rendered container now has an explicit API. Use `ReactDOM.hydrate` instead of `ReactDOM.render` if you're reviving server rendered HTML. Keep using `ReactDOM.render` if you're just doing the client-side rendering.

For more information, check out the full list of [deprecations and breaking changes on GitHub](https://github.com/facebook/react/releases/tag/v16.0.0).

There has been a lot of performance observation and testing done by apps that have made the upgrade to ReactJS 16. And so far, there have been a lot of cheer and positive feedback for ReactJS 16. In fact, Twitter Lite already uses ReactJS 16.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Twitter Lite is now on React v16. We&#39;ve seen from 5 to 32% increase in performance on React components. 🎉👏</p>&mdash; Paul Armstrong (@paularmstrong) <a href="https://twitter.com/paularmstrong/status/920700461388361728?ref_src=twsrc%5Etfw">October 18, 2017</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

The Twitter Lite engineering team discovered that the app's bundle size reduced a little and there were very clear improvements on large trees.

<include src="asides/React" />

## Conclusion

ReactJS is an awesome front-end library to employ in building your user interfaces. It is faster now because it runs on _React Fiber_ and allows you to build more performant, smoothe UIs for your web and native applications.

**ReactJS 16** came loaded with lots of new features and significant improvements. Kudos to the ReactJS team and the JavaScript open source community for all their efforts in making ReactJS a better tool.

Have you switched to ReactJS 16 yet? What are your thoughts? Let me know in the comments section! 😊


React 16 Release: What’s New?

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

Inferno is a fast, small, React-like JavaScript UI library.

Learn About Inferno JS: Build and Authenticate an App

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

Learn about functional data structures and their uses in this overview of Facebook's popular library for JavaScript: Immutable.js

Introduction to Immutable.js and Functional Programming Concepts

Damian Schenkelman

Damian was one of Auth0's earliest employees. He loves building products for developers and taking things from 0 to 1.
<br><br>
He played key roles in implementing product features and growing the engineering organization in the early stages, and later on defining Auth0's architecture for scale and creating new products. Today he helps shape Auth0's long term strategy and leads Auth0Lab, a small and amazing team doing research and development of forward-looking products.
<br><br>
He spends his spare time with family, and friends, exercising, and catching up on all things NBA.

VP R&D (Auth0Lab)

Learn how we deploy new versions of features while avoiding breaking changes through the use of a node.js library for feature changes.



**tl;dr**: We created a [node module](https://github.com/dschenkelman/feature-change) to run two versions of a feature at once (original and new), compare the results, and always return the original results. It is useful in deploying new versions of features without breaking changes.

-------------

At Auth0, we move fast — I mean _really_ fast. Last Friday alone (yes, Friday), we performed  14 deployments to production.

This is something I really like and a positive thing in general, as for example it allows us to do things like [fixing production bugs in short timeframes](https://twitter.com/trydis/status/642809967859380224). Shipping fast is great, but we can't do it recklessly, because stability and availability are core concerns for us. And I'm not just talking about our service, but also about the contracts we commit to in our APIs and SDKS. We never break compatibility, unless there's a security concern involved.

<include src="TweetQuote" quoteText="Shipping fast is great, but we can't do it recklessly. Stability and availability are core concerns for us."/>

To prevent issues, one option is to move slower. Another option is to start relying more on tools and automated tests to make sure that deployments do not introduce any breaking changes.

We settled on a hybrid approach. On the one hand, we host segregated production clusters with different release cadences. One of the clusters gets updated on every change we make, and the other one gets a batch update with a one day delay (approximately). On the other hand, we constantly improve the automated tests that run in our build server before each release, to include additional checks before new versions are deployed to production.

One tool we created is a node module named [feature-change](https://github.com/dschenkelman/feature-change). We got the idea from a blog post by [@holman](https://twitter.com/holman) explaining how GitHub [moves fast & breaks nothing](http://zachholman.com/talk/move-fast-break-nothing/). I think it is best to tell you how it works using a real life example.

# Example: Moving search from MongoDB to ElasticSearch
It all started with a new requirement from one of our customers:

> Is there a way to search for users by field XYZ?

There wasn't, so we went ahead and implemented search against our small MongoDB instance. And all was good.

After that, we had a request from another customer:

> Is there a way to search for users by field ABC?

Then, we had another request, so we decided to allow searching by any field, providing some sensible defaults for the common cases. For a while, this worked perfectly, but as our customer base (fortunately) grew, we realized MongoDB wasn't exactly built for this kind of thing.

For v2 of our API, we had learnt our lesson, so we did not allow searching against MongoDB. Instead, we relied on Elastic Search for this use case, which is working as expected so far.

However, some of our customers are still on v1 of our API. Some of their searches against MongoDB were really slow, affecting the database's stability. So, we decided to exactly replicate the v1 search functionality in ES to reduce the load on our database.

# Introducing feature-change
We know a LOT of our customers rely on search, so we didn't want to introduce any issues with this change. For that purpose, we decided to take advantage of the idempotency property of a search operation to deploy a temporary version to production that did all of the following:

* Perform the search against MongoDB
* Perform the search against ES
* Compare the results and write them to our logs if there was a difference
* Always return the MongoDB result

Using `feature-change`, it looked like this:

```js
var feature_change = require('feature-change');

var current_implementation = mongo_search;
var new_implementation = es_search;

feature_change(function(cb){
    current_implementation(current_opts, cb);
}, function(cb){
    new_implementation(es_opts, cb);
}, function(mongo_result, es_result){
    // invoked when there is a difference in the results (useful for logging)
}, function(err, result){
    // this is the original callback we were using for mongo
    // err and result always come from mongo_search
});
```

We ran this version in production for a couple of weeks and used our logging infrastructure (Kibana/ES) to log the differences. Kibana provides a very useful feature that allows you to create stack charts based on counts of a certain event. In the following chart, the blue part represents the relative percentage of differences compared to successful results. In other words, the blue bars show breaking changes, which we wanted to reduce.

![node module feature-changes](https://images.ctfassets.net/23aumh6u8s0i/5asBdv1p0v3aY26k7h5P2A/1652ea089e8017c2dd32dd0a3edf4c37/parallel-code-paths-1)

After fixing three different bugs we got rid of all the blue. We monitored the differences for a week to see if any new sources of errors appeared. When they didn't, we removed the code using `feature-change` and completely replaced MongoDB with ES in production.

# feature-change is Open Source
We have [open-sourced](https://github.com/dschenkelman/feature-change) `feature-change` so you can use it in your own Node.js applications. Feel free to open issues, send PRs, etc.


Applying GitHub's Parallel Code Paths using Node.js in Auth0

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Learn the essentials of Falcor--the newly open-sourced library from Netflix that lets you represent your data as a single virtual JSON object.

Getting Started With Falcor

42e2ec6a72627f8c15115e279a5f7d8e

Ben Schwarz

Introducing an official 'ember simple auth' add-on



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Visit <a href="/blog/build-and-authenticate-an-emberjs-3-application/">Build and Authenticate an EmberJS 3 Application</a> to read our most up-to-date tutorial.</strong>
</div>

<div class="alert alert-danger alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>This tutorial has been deprecated.</strong>
</div>

__TLDR;__ Install the add-on using ember-cli `ember install auth0-ember-simple-auth`, or checkout the generated [example application](https://github.com/auth0/auth0-ember-simple-auth/tree/master/examples/simple) to get started.

-------

At Auth0, we’re huge fans of [Ember](http://emberjs.com), the Javascript framework made famous for writing ambitious single page applications (also known as SPA).

Unfortunately, up until now our support and resources for Ember have not equalled our enthusiasm for it. Thankfully, starting today, we have some great news —

![Auth0 + Ember logos](https://images.ctfassets.net/23aumh6u8s0i/1OmRtzhY0B2pQjr7zmQvDF/042e08bfa6bceb14b1216c9b2af0594a/auth0-ember)

# Introducing an official 'ember simple auth' add-on

For those familiar with Ember, it might go without saying that “[ember-simple-auth](http://ember-simple-auth.com)” is the most popular authentication helper library around. It implements a strategy based plugin system that allows users to write their own custom authentication strategies.

That is exactly what one of our customers, [Aram Zadikian](https://github.com/brancusi) did, and thanks to his generosity, we’re able to share his fantastic work with you today!

We'll be maintaining `auth0-ember-simple-auth` on an ongoing basis, so you can rely on it to build your ember applications.

## What does it do?

`auth0-ember-simple-auth` is an Ember-cli add-on that uses [Lock](https://auth0.com/lock), and, after some simple configuration will allow you to sign up/in and out — protecting whichever pages you've specified in your router.

```
// app/routes/application.js

import Ember from 'ember';
import ApplicationRouteMixin from 'simple-auth/mixins/application-route-mixin';

export default Ember.Route.extend(ApplicationRouteMixin, {
  actions: {
    sessionRequiresAuthentication: function(){
      // Check out the docs for all the options:
      // https://auth0.com/docs/libraries/lock/customization

      // These options will request a refresh token and launch lock.js in popup mode
      var lockOptions = {authParams:{scope: 'openid'}};

      // This tells simple-lock to use our `auth0-ember-simple-auth` add-on
      this.get('session').authenticate('simple-auth-authenticator:lock', lockOptions);
    }
  }
});

```

Now that you have enabled your simple-auth strategy, its just a matter of importing the `AuthenticatedRouteMixin` from `ember-simple-auth` to lock down routes that need to be protected.

```
// app/routes/my-protected-route.js

import Ember from 'ember';
import AuthenticatedRouteMixin from 'simple-auth/mixins/authenticated-route-mixin';

export default Ember.Route.extend(AuthenticatedRouteMixin);
```

Now you've already got a secure single page application. Time to focus on writing your app!

![A sample application in use — Running through an authentication flow](https://images.ctfassets.net/23aumh6u8s0i/5QVfIyB3z912z95cgeJ8aw/31297f25190488606cf5508938904367/ember-simple-auth)

You can install & run the `auth0-ember-simple-lock` add-on, or, to fast forward to a fully working ember application (shown above), you can download the seed project from [your application dashboard](https://manage.auth0.com/#/applications).

We can't wait to see what you do with ember, make sure you [reach out on Twitter](https://twitter.com/auth0) with what you create.

✌️ Happy hacking!


Ember + Auth0

b93af62499ed0f76f280acb37913f15d

Hernan Zalazar

A few weeks back we released the first version of our native iOS SDK to help you add authentication to your app. We needed a Keychain library that supported

A few weeks back we released **the first version of our native [iOS SDK](https://github.com/auth0/auth0.ios)** to help you add authentication to your app.

We needed a **Keychain library** that supported the following features:

* **TouchID Support**: An option to make a private keychain value only available if the user entered his fingerprint
* **Accessibility options**: An option to state wether the keychain value could be got if the iPhone is Locked, Unlocked or in which state
* **Shared Group**: We needed Shared Group support so that 2 different apps could share keychain values

As there was no library that fulfilled our needs, **we decided to build [SimpleKeychain](https://github.com/auth0/SimpleKeychain)**.

Let’s see some of the different use cases that we’ve created and used.



## How do I store a value (e.g. JWT Token) in the Keychain?

```objc
NSString *jwt = //user's JWT token obtained after login
[[A0SimpleKeychain keychain] setString:jwt forKey:@"auth0-user-jwt"];
```

```swift
let jwt = //user's JWT token obtained after login
A0SimpleKeychain.keychain().setString(jwt, forKey:"auth0-user-jwt")
```

## How do I share a value (e.g. JWT token) between different apps?

When you have a family of apps that need to share the same user session, you can use iOS Keychain Sharing to store the token. That token must be stored under the same Access Group.

First in one of your apps save the JWT token:

```swift
let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup: "ABCDEFG.com.mydomain.mysharegroup")
let jwt = //user's JWT token obtained after login
keychain.setString(jwt, forKey:"auth0-user-jwt")
```

Then, you obtain the token in the other app:

```swift
let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup: "ABCDEFG.com.mydomain.mysharegroup")
let jwt = keychain.stringForKey("auth0-user-jwt")
```

## How I can handle the accessibility of the items saved in the keychain?

If you want to restrict when the item can be retrieved (For example only when the iPhone is unlocked, or if you want the entry to be included in any backup) you need to specify the item accessibility before saving:

```objc
A0SimpleKeychain *keychain = [A0SimpleKeychain  keychain];
keychain.defaultAccessibility = A0SimpleKeychainItemAccessibleWhenUnlockedThisDeviceOnly;
NSString *jwt = //user's JWT token obtained after login
[keychain setString:jwt forKey:@"auth0-user-jwt"];
```

## How can I trigger TouchID prompt before accessing the Keychain?

With the release of iOS 8, a new feature was added in order to tie a Keychain item to the user's passcode or their fingerprints .In order to use this feature, you need to store the value with accesibility `A0SimpleKeychainItemAccessibleWhenPasscodeSetThisDeviceOnly` and using iOS 8 Keychain Access Control:

```swift
let keychain = A0SimpleKeychain.keychain()
keychain.defaultAccesiblity = .WhenPasscodeSetThisDeviceOnly
keychain.useAccessControl = true
let jwt = //user's JWT token obtained after login
keychain.setString(jwt, forKey:"auth0-user-jwt")
```

Then whenever you query for that item a prompt will appear and the user will have to enter their fingerprint or passcode:

```swift
let message = NSLocalizedString("Please enter your passcode/fingerprint to login with awesome App!.", comment: "Prompt TouchID message")
let keychain = A0SimpleKeychain.keychain()
let jwt = keychain.stringForKey("auth0-user-jwt", promptMessage:message)
```

This is just a glimpse of all that you can accomplish with [SimpleKeychain](https://github.com/auth0/SimpleKeychain).

Add it to your **Swift or Objective C** project now with CocoaPods and start using it!:


```ruby
pod 'SimpleKeychain', '~> 0.1'
```

"library"