Share and Reuse functionality with libraries in Nx
Scaling development across large teams and organizations isn't always just about having fast builds or CI runs. It is also about being able to implement scalable architectural patterns. Nx helps you split up your functionality into libraries and help you think about their corresponding public/private APIs. This process facilitates the creation of more reusable units which is exactly what we're going to explore in this lesson.
Instructor: [0:00] Right now our application consists of that store app as well as the API. Currently, we fetched these game examples from our API, which lives at localhost:4200/api/games.
[0:14] For detail pages, as you can see, they are poor right now. They just show the actual title, which is being read directly from the URL. Now, what we want to do is we can use that URL to fetch the detail of the game.
[0:28] We can basically here pass in the actual ID, and that will get the detail of that single game. Let's incorporate that in the detailed view and make it a bit more rich. Let's open up our libraries folder, store feature game detail, and go to the actual component.
[0:47] Again here, we will import the useEffect and useState from React. Similar to what I've done in the app component, I'm not going to go too much into the details of the implementation of the actual API fetch, because that's not really the point of our video course here.
[1:06] What happens here is I'm using again a state that shows basically the difference between success, error, and loading. Then, in the useEffect, I'm fetching the API games by using the actual game ID that comes from the URL.
[1:21] Further down in our rendering area, we can now render these cards here based on where the data has come from the server. When we have loading state, we just showed it loading... we handle the error case with just showing a diff with an error message.
[1:38] Whenever the data is present, we can actually then render this card here. We need to make sure to close here parenthesis again. Let's reformat it with prettier, and let's also add some more content in here rather than just ID.
[1:53] First of all, we can show the image and for our purpose, we have to import the card media. Let's directly import it here from Material-UI and in content area here, let's also add the name rather than the ID.
[2:10] Again, our web server runs behind the scenes. If we go back and refresh here, we can see that actual game below here refreshes properly. Now, let's do another thing and add also that rating.
[2:21] If you go back to our detail, let's just directly add it below the name. I'm copying here in a piece of code that takes the rating from the data and visualizes it. If we go back and refresh, we see that we still are missing the actual formatting, which we have up here.
[2:37] Since our formatting lives in a shared library, reusing that within our game detail is simple. Our format rating lesson at util.formatters, which is here in the store util.formatters, where we have that format rating.
[2:53] Similarly, as we did in the app.tsx file, if we scroll up again, we import that format rating and then further below here, we use that format rating to properly format the rating on the UI.
[3:06] In this very same way, we can go to our store detail component, we can go here and import the format rating. Then we copy it here, and go down here until we reach our rating part and we invoke it. Let's save again. Let's switch over to our browser, and we see now that the rating is properly formatted.
[3:27] Let's also inspect now the dependency graph to see how that changed. If we switch back and activate everything, we see that the dependency graph now changed slightly. Now we have our store application. We have our feature game detail and the store UI shared.
[3:48] We also see that the store feature game detail also references the story to formatters, just as does the store application, which has our app.tsx component.
[3:59] Basically, by having extracted already from the very beginning certain utility functionalities into a separate library, you can see how easily it can then be reused across various order libraries without changing our code.
I'd be interesting in see how you'd handle publishable and buildable libraries, and how those are used in apps, as well as how they are used when imported into one another. For instance, a publishable library importing a buildable library.