DEV Community: Stas Kohut

NX for React

Stas Kohut — Wed, 03 Aug 2022 04:34:00 +0000

Intro

Hello everyone, my name is Stas Kohut. I'm a frontend developer and have been doing frontend for 8 years. During those years, I participated in numerous projects using different frontend technologies. But recently, I have stuck to the React ecosystem, so I'll speak from React developer's perspective in today's post. However, it can be applied to any frontend technology so stick around.

A little disclaimer: I'll try to tell a story rather than read it as a manual. It's not a tutorial! Given that there won't be any code examples. My goal is to raise awareness of the technologies and maybe spark someone's interest to do some research for themselves on the topic. And maybe after that, you would want to use it in your next project.

What's NX?

In short, it's a developer experience (DX for short) toolkit that helps building projects inside monorepo architecture. Think of it as create-react-app (or angular-cli) for monorepos.

So it might be obvious from the name: monorepo stands for the mono repository - a repository that contains all domain-related files. And I mean ALL files: your backend, your frontend, your utility libraries, documentation, etc. In opposition to that, polyrepo is the approach where each of your domain-related projects has its own repository. I couldn't find when the first monorepo was created. Still, Wikipedia says this approach dates from the early 2000s and is currently widely used by Google, Facebook, Microsoft, and other large and small companies.

Knowing what monorepo is, we can say that NX is a tool to manage monorepos. It was created by ex-google employees who worked on Angular.js and Angular in particular: Jeff Cross and Viktor Savkin. In 2016 they left to start their own consulting firm Narwal Technologies Inc (Nrwl for short), and 2 years after, they released the first alpha version of their own monorepo manager.

Being angular guys to the bone, the first versions supported only angular projects. Heck, they even used literal angular.json for their config. A bit later, NX became a framework agnostic. At first, the meat of this tool was a great set of generators for various frameworks that made starting an app a single command job (create-react-app wink-wink). And they didn't stop on it and added a bunch of stuff: a visual inspector of the dependency graph, github actions, cloud caching, and so on.

That's all cool, but you might ask yourself why you need it. And most importantly, why choose NX over other options: Lerna, Turborepo, Bazel, or even npm/yarn workspaces (and the list goes on)?

Okay, the answer to the first question depends on your situation and preferences. As I mentioned, I'm here to share, not sell. So, you'll need to do the homework yourself. I found a great page about the pros and cons of both approaches. If you decide to try monorepo, be my guest and suit yourself with whatever option is available. I can share an excellent website that might help you decide https://monorepo.tools/. My story of using NX is based on occasion and curiosity, but I'll tell it later.

Next, I want to talk about some use cases. And although I'll be talking about NX, most of the stuff applies to other monorepo tools.

How can you use NX?

The prime example of the setup is to have both the API and the client project in the same repo. You can run everything with a single command, share typings, and develop full-stack features without switching between editor windows. You might think it's most suitable for full-stack developers. In some way, it is. But as a dedicated frontend or backend developer. Sometimes you want to peek at what the heck is going on over there: how the endpoint builds the response or how the frontend handles your API. But often, you even don't have access to other team repo. I know. I've been there.

NX nicely fits the microservices architecture: small isolated applications that might have some shared interfaces of utilities.

Of course, you can argue that it might not always work. Not all benefits can be used. And it's true, NX works great with JavaScript frameworks only. If your backend is not Node.js based, you won't be able to use it. I invite you to learn about other language-agnostic tools here.

Another example is to use it for libraries. For instance, UI-kit. I often see that a theme, icons, basic components, and advanced components are separated in such libraries for consumer convenience. It's reasonable to release them separately. The end user might not need all of the packages. And NX shines here, allowing you to develop everything together but release it separately.

Also, you can use it for a single frontend (or backend) project. At first, it may not have any sense. Why would you need a monorepo for a single project? But NX has a trick up its sleeves - the libraries structure. You see, NX provides a way to have shared libraries area between several applications. Nothing unusual. However, they introduce libraries types approach where you should put your libs under 4 basic categories: feature, data, UI, and utils. It helps structure application by layers. All API interactions code and state management should go to data libraries. UI components - to UI libraries and so on. Since it's just a convention, you can just ignore it altogether and use it as a basic area for shared code. Or you can create your own types of libraries to fit your needs in the project. For instance, we wanted to share typings separately at some point and made a types-library type of signaling that typings should go there.

Library categories have a dependency constraint, meaning a specific library type can depend only on a particular type of other libraries. For example, UI components usually shouldn't interact with the API directly. This is a job of a container. So following that, UI libraries shouldn't import any data libraries. Or utils shouldn't depend on anything other than maybe other utils. And it's reflected in libraries hierarchy. By default, it's not enforced and is just a convention, but NX provides a tool to prevent unwanted imports.

Those are just examples that I’m more familiar with. NX supports various JavaScript frameworks and tools, so it’s a good chance it already supports what you want to achieve.

My path with monorepos and NX

My first encounter with monorepo was way back in 2017. I ended up on a project that has its own UI library, and this library was a Lerna-based monorepo. I didn't participate in choosing the monorepo approach or the tool. It was already there. But I liked the approach because all components depended on a theme, and it was straightforward to navigate a single project during its development. Also, releasing all libraries as separate libraries from a single repo seemed like magic to me at the time. Eventually, as angular libraries matured, we replaced Lerna with the native angular solution, which looked like a better option from the support view.

The next time I worked with monorepo was a few years later. In 2020 we were starting a new project, and the setup was very similar to the first project: an app and a UI library. We started developing the UI library first. And because we already used Lerna, the choice was a no-brainer. However, once we were about to start developing the app, NX began to gain popularity. They introduced React support, and out of curiosity, we began investigating it. The libraries hierarchy appealed to us, and we decided to give NX a shot with the app. Although we never had a chance to convert the UI components library to NX.

At the end, it was a good choice. The project structure looked clear and easy to follow (once you wrap your head around NX concepts). Dependency constraints prevented us from doing silly stuff (most of the time). So, needless to say, we started to use NX in all oncoming projects.

I never used NX with the backend project in the production, but I had some toy projects exploring that idea, and I liked it.

Another "success story" using NX was on a project where we developed a chat widget. It was not a standalone app and intended to be integrated into different environments we didn't own. We came up with an idea to create a hoster app that will simulate all possible environments to test our widget without a dependency on another team. NX was an excellent fit for such requirements because we didn't have to pollute our main app (the widget) with the throwaway test code. It lived as a separate app inside the monorepo.

By the way, we liked the idea of the hoster app, and for the next project we did, we created a similar app to provide a dynamic environment config for the main app. But it's a story for another time.

Struggles

You might think that since I shared only success stories, it means that all went nice and smooth. Unfortunately, it's not always great, and monorepos and NX, in particular, have their own set of problems.

I want to start with the documentation. The NX team provides a ton of learning material: they have a video course, books, and even their own conference. And they improved their docs throughout the years significantly. However, the API documentation is not ideal. Whenever I want to find a command to rename a library or delete it, I struggle to find anything in their doc. And it's usually faster for me to just google it or even do it manually (don't do it, though). It would be good to have the page with the most common commands because, honestly, it's all you need 90% of the time, yet there's none. Or I couldn't find it, which isn't speaking in favor of the docs as well.

The next struggle is not a big issue anymore, but it was previously. I'm talking about low-level access to the webpack config. I think Angular started this trend, and NX developers followed it for some reason. Maybe it's their Angular roots. I don't know. It was a painful to get to the config. We had to use patch-package util to overwrite config directly inside the node_modules folder to make the change we needed. Luckily it's not the case anymore. You can provide a custom webpack config per application without needing a 3rd party package.

The NX team follows the single-version policy. Meaning if you need to maintain several different versions of the same dependency, you better look elsewhere. I think it's one of the rare cases, but we totally had it. On one of the projects, we used an in-house package that required a specific version of React. But in our repo, we already moved on to a newer version. Although I think some hacks might help you achieve it, we couldn't make it work for us. Likely we could convince the team that maintained the package to put the upgrade in their roadmap sooner. However, it could quickly become a serious problem for us.

Last but not least, and maybe the most prominent issue with monorepos, is bloating of the sources. Besides all the boilerplate files, you basically cram all of your projects into a single repo. It can and will affect your install time and your build time. Currently, in our project, it takes 20 minutes to release a version. And it's for a frontend app and without tests! About 7 minutes takes to install all dependencies which might not be relevant to the app we're about to release. And about the same time to run the build command. Plus a bunch of other smaller scripts. In our case, it's manageable: we're going to reduce the number of dependencies as we get rid of the legacy. Also, we're still running node 12, which is way slower than 16 in terms of npm install. Although those issues are partially on our side, I imagine it wouldn't be so drastic in polyrepo architecture.

By the way, fun trivia: Google runs all their codebase in a single monorepo that contains 2 billion lines of code representing 86 Tb of storage. You can read more about it here.

Conclusions

As I started learning and using more technologies, people asked me what I liked better: the framework I used before or the one I'm using now. I always answer: it doesn't matter to me. A tool is a tool. But the more you use a tool, the more familiar you get with it and more proficient. And after some time, you would prefer your current tool over others, maybe not because you like it the most, but because you're more comfortable with it. It becomes your preference.

I know there's always debate over the right tool for a job, but the truth is most of the time, it comes down to preference and resource availability.

It's not always unicorns and rainbows with NX. But it has proven to be an excellent tool for various projects. I know I'll most likely use it in my next project. It became my preference.

I invite you to read more about it, to be aware of such a tool. Maybe you would also want to try it in your next project.

Thanks

I'd like to thank @eransakal and @amirch1 for their feeback. Check out Eran's blog.

#StandWithUkraine 🇺🇦

It's been 5 months since russia waged a full-scale war against my homeland. We're still strong, fighting, and will continue to fight until our victory. Stand with Ukraine and support us.
The best way is to donate to those charity foundations:

Every penny counts!

RxJS Operators decision table

Stas Kohut — Fri, 11 Dec 2020 09:25:19 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1039590397943705602-300'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1039590397943705602&theme=dark" }

I like this joke yet I think it's obsolete.
I remember myself 4 years ago trying to comprehend all the concepts behind reactive programming, learning ways to write my streams and manipulate them using operators. It wasn't easy besides you had to keep up with all new changes (and there're a few of them). But today RxJS is a mature toolchain with a lot of learning materials, the amount of effort the team puts into making the library more accessible for common folks like me is truly impressive.

Yet it's still a common opinion that RxJS is not very friendly for newbies. Besides core concepts of reactive programming (that are not specific to RxJS), the number of operators available for a user might be intimidating.
As I stated above, the maintainers' team did and doing a great job simplifying and improving the API. And luckily we don't need to remember all of them as a tiny portion is actually needed for everyday use.

Still, you can find yourself a bit lost thinking of what operator should I use in certain cases. Don't worry the docs got you covered, it contains a super useful operator decision tree util https://rxjs.dev/operator-decision-tree. Answering simple question about your intentions with the stream it can suggest the most fitting operator for your case.

It's great, but I prefer the table view of the same tree. And unsurprisingly there's such a table https://xgrommx.github.io/rx-book/content/which_operator_do_i_use/index.html, but there's another "but" – it's a bit outdated thus I present you the up-to-date (at the time of writing this post) version of the same table:

Creation operators

I want to create a new sequence	using custom logic			Observable (class)
		that works like a for-loop		generate
	that throws an error			throwError
	that completes			EMPTY (const)
	that never does anything			NEVER (const)
	from an event			fromEvent
		that uses custom functions to add and remove event handlers		fromEventPattern
		over the values in an array	of object key/values	pairs
		over values in a numeric range		range
		over the values in an iterable, a Promise, array or array-like object		from
		over arguments		of
	that emits values on a timer			interval
		with an optional initial delay		timer
	decided at subscribe-time	based on a boolean condition		iif
		using custom logic		defer
			that depends on a resource	using
I want to combine multiple sequences	and only receive values from the sequence that yields a value first			race
	and be notified when all of them have finished			forkJoin
	and output the values from all of them			merge
	in order	reusing the latest value when unchanged		combineLatest
		using each value only once		zip
	by subscribing to each in order	when the previous sequence completes		concat
		regardless of whether the previous sequence completes or errors		onErrorResumeNext

Stream operators (ex instance operators)

Using an existing sequence	I want to change each value			map
	I want to pull a property off each value			pluck
	I want to be notified of values without affecting them			tap
	I want to include values	based on custom logic		filter
		from the start of the sequence		take
			based on custom logic	takeWhile
		from the end of the sequence		takeLast
		until another sequence emits a value or completes		takeUntil
	I want to ignore values	altogether		ignoreElements
		from the start of the sequence		skip
			based on custom logic	skipWhile
		from the end of the sequence		skipLast
		until another sequence emits a value		skipUntil
		that have the same value as the previous		distinctUntilChanged
			based on object by key	distinctUntilKeyChanged
			by selector	distinct
		that occur too frequently		throttle
			based on duration	throttleTime
		by emitting the first value in each time window		debounce
			based on due time	debounceTime
		by emitting the last value in each time window		audit
			based on due time	auditTime
	I want to compute	using custom logic	and only output the final value	reduce
			and output the values as they are calculated	scan
			and output observables as they are calculated	mergeScan
	I want to wrap its messages with metadata	that describes each message		materialize
		that includes the time past since the last value		timeInterval
		that includes a timestamp		timestamp
	after a period of inactivity	I want to throw an error		timeout
		I want to switch to another sequence		timeoutWith
	I want ensure there is only one value	and throw an error if there are more or less than one value		single
	I want to only take the first value	and throw an error if there are no values		first
		within a time period		sample
			based on period	sampleTime
	I want to only take the last value	and error if there are no values		last
	I want to know how many values it contains			count
		by all of its values		every
	I want to delay messages by a specific amount of time			delay
			based on custom logic	delayWhen
	I want to group the values	until the sequence completes		toArray
		using custom logic	as arrays	buffer
			as sequences	window
		in batches of a particular size	as arrays	bufferCount
			as sequences	windowCount
		based on time	as arrays	bufferTime
			as sequences	windowTime
		based on observable	as arrays	bufferWhen
			as sequences	windowWhen
		based on a key	until the sequence completes	groupBy
	I want to start a new sequence for each value	and emit the values from all sequences in parallel		mergeMap
		and emit the values from each sequence in order		concatMap
		and cancel the previous sequence when a new value arrives		switchMap
		and recursively start a new sequence for each new value		expand
	I want to combine it with another	And be notified when both have completed		forkJoin
	I want to share a subscription between multiple subscribers	using a specific subject implementation		multicast
		and start it as soon as first subscriber arrives		share
		and start it manually or imperatively		publish
		and supply the last value to future subscribers		publishLast
		and replay a default or the latest value to future subscribers		publishBehavior
		and replay n number of values to future subscribers		publishReplay
	when an error occurs	I want to re-subscribe		retry
			based on custom logic	retryWhen
		I want to start a new sequence		catchError
	when it completes	I want to re-subscribe		repeat
I want to start a new sequence		concat
when it completes or errors		I want to start a new sequence		onErrorResumeNext
when it completes, errors or unsubscribes	I want to execute a function		finalize
I want to change the scheduler that routes	calls to subscribe		subscribeOn
	messages		observeOn
Using two sequences	I want to decide which to receive values from	based on which one has values first		race
	I want to determine if their values are equal			sequenceEqual
	I want to combine their values	only when the first sequence emits, using the latest value from each		withLatestFrom
		in order	reusing the latest value when unchanged	combineLatest
			using each value only once	zip
	I want to include values from both			merge

If you're new to RxJS be sure to check out Eran's beginner guide post

Understanding RxJS - Learn From Examples - Part 1

Eran Sakal ・ Jun 30 '20

#beginners #rxjs #angular #javascript

Keep hacking my dudes 😉