Disclaimer: I use Amazon affiliate links below.

I enjoy the digital nomad lifestyle, so I often work on the road. I write code, do consulting, create presentations, and author courses. Here are the tools I bring along for the ride.

My Backpack

MacBook Pro 15

I preferred the old 2015 keyboard and don’t use the TouchBar. So why’d I buy this?

• The SSD is faster than the 2015.
• It’s thinner and lighter than the 2015.
• The screen is notably brighter, so I can easily work outside. (Apple’s anti-glare screen tech is much better than today’s mirror-like touchscreen displays)
• TouchID is handy.
• USB-C makes it easy to dock. I use Apple’s HDMI with USB and power dongle when traveling. I put a few cheap USB-C to USB-A adapters on existing USB-A peripherals.

My full review

Verizon Mifi

Verizon 7730L Mifi — I’ve tethered to my phone for years, but it always annoyed me. Poor signal, slow speeds, quick battery drain, and it tied up my phone so I couldn’t do calls while online. This is so fast it feels almost like I’m home, the battery lasts 24 hours, and its been consistently fast and reliable everywhere I’ve used it.

The Roost Stand

The Roost laptop stand — I absolutely love this thing. No more looking down at a screen. This avoids neck pain by placing the screen at eye level. It improves my mood too (looking down is a mental downer too).

I use this on planes so I can read without being cramped. It fits nicely on a tray table. And since it places the machine above the tray table, it leaves room on the tray table for the separate trackpad and a drink.

Related tweet
Another related tweet

Apple Airpods

AirPods. These sound fantastic and are so comfortable I forget they’re in my ears. I like how they pause when I remove one, and a double tap on the side switches to the next track. I bought silicon covers for biking but found they’re not necessary — I’ve never had one fall out.

Bose Headphones

Bose QC35 Noise Cancelling Headphones — I mostly use these on planes and in loud environments. They do an excellent job at cutting noise on flights, noisy airports, and team rooms.

Apple Magic Trackpad 2

Magic Trackpad 2 — I was surprised to fall in love with this. Using a built in trackpad on a laptop can lead to hand cramps, but that’s just because of the awkward wrist angle they tend to create when a laptop is on your lap. Since this is placed in a normal mouse location, I find it very comfortable. I like being able to use the same gestures as on my MacBook’s trackpad. So my workflow doesn’t change when I dock. And since I can place my hands however I like, I find it very comfortable. Also, since I travel a lot, being able to just sit this on any surface is a win — unlike a mouse which can be picky about surfaces. It’s flat and light, so it fits easily in my bag.

Apple Magic Keyboard 2

Magic Keyboard 2 — The worst thing about the new MacBook Pros is the keyboard. The Magic Keyboard 2 has the same key feel as the old MacBook laptops. 👍 And since I like to use my machine on the Roost stand, I need an external keyboard. This is flat, light, wireless, and durable, so it’s perfect for travel.

Logitech Presenter

Logitech R800 Wireless Presenter — I like this because it has a countdown timer, long battery life, and excellent range. Pro tip: Here’s how I avoid forgetting to start the countdown timer: I start the countdown timer before the talk begins. I just set the timer to the length of the talk plus the number of minutes until the talk begins. (so if it’s an hour long talk and I’m starting the timer 15 minutes before the talk, then I set the timer to an hour and 15 minutes and press start).

Anker Battery

Anker Powercore 10000 USB Battery — This 10,000 mah battery has enough juice to charge my phone, headphones, and Verizon Mifi multiple times so I don’t worry about running out of juice. And it’s about the size as a deck of cards!

Apple iPhone 7

I’ve had Android for years but recently switched because iPhones benchmark significantly faster. Performance is the most important feature to me, and so far this has been quite snappy. I also like iPhone’s integration with Mac. It’s handy getting text messages and calls forwarded to my Mac so I can leave my phone plugged in outside my office which aids focus.

Other items in my backpack:

• Outdoor coding kit: Hat, sunglasses, and sunscreen
• Airport/coffee shop kit: Plugin adapters (useful so I can share an outlet with others), an extension chord (again, useful when I can’t get close enough to an outlet)
• Sleeping kit: Mask and earplugs for sleeping on airplanes
• International travel: Not pictured, but I bring a couple of these universal AC power plug adapter when traveling internationally.
• USB to lightning cable — For charging phone, AirPods, Trackpad, keyboard. The benefit of using all Apple is I can use the same cable to charge all 4 of these wireless peripherals.
• Second monitor in a pinch: I carry a 6' HDMI cable. Handy when a conference is lacking one. I also use it to attach my machine to the hotel TV so I can enjoy a second monitor on the road. I typically prefer a single monitor, but this is useful when video conferencing so I can put the video call on one screen and work on the other. Sometimes I put concerts on the 2nd screen so I don’t feel so alone in hotels. :)

Here I’m using the hotel TV as a 2nd monitor via HDMI:

Hardware I use at Home

Here’s the equipment I use at home.

Dell 27" 4K Monitor

Dell P2718Q 27" 4K Monitor — I love this display. Perfect size, beautiful IPS panel, and attractive small bezel design.

My tweet about it

Monoprice USB-C Adapter

Monoprice USB-C to 3x USB-A 3.0, Gigabit Ethernet & USB-C Adapter — When I get home, I dock my Mac with this. The only other cable I plug in is the USB-C cable running out of my 4K monitor. I have Google Fiber, so it’s great plugging this thing in and enjoying gigabit speeds! 🏎

Veridesk Pro

Veridesk Pro Adjustable Stand Up Desk Converter — I placed this on top of a traditional desk so I can stand when desired.

Lifespan Treadmill Desk

Lifespan TR1200 DT Treadmill — I enjoy walking while working. Studies show walking while reading improves focus memory retention. I find it also keeps me alert. I alternate between walking, standing, and sitting depending on my mood. When I want to sit, I wheel this back, put my chair in front of the desk, and collapse the Veridesk to sitting mode by pulling two levers to lower it.

Sculpt Keyboard

Microsoft Sculpt Keyboard — I love this keyboard. Best keyboard action I’ve found, and the ergonomic design is quite comfortable. I’ve used it when traveling too but switched to a Magic Keyboard 2 because the Sculpt isn’t flat which bloats my backpack, and it’s small F-keys tend to get jammed down when it’s stuffed in a backpack (the sole downside I’ve found). I like that this keyboard comes with a separate number pad. This way the reach from the keyboard to the mouse is shorter. 👍

Apple Magic Trackpad 2

Magic Trackpad 2 — Yes, I like this so much that I have a second for home.

Ergotron Monitor Arms

Ergotron Dual Monitor Arms — I put my Dell 27" on one, and my Mac on the other using the Ergotron laptop tray which attaches to the monitor arm. I typically only open my Mac for video conferencing since I prefer a single monitor setup. I run them side-by-side, but these arms support stacking too. I bought the stacking style since it gives you more vertical height adjustment for side-by-side arrangements.

Rode Podcaster Mic

Rode Podcaster attached to a Rode Boom Arm. — I recorded all my Pluralsight courses and podcasts on this mic. The USB interface makes it easy to work with.

One More Odditity

My wife makes fun of this, but I occasionally work from the car too. So I use a steering wheel desk from eBay. This is handy when I’m waiting for the kids while they’re at practice and events. I drop them off and wait there instead of driving back and forth. So this saves time and money. On nice days, it’s also enjoyable to drive somewhere inspiring and quiet so I can work from there for awhile. This works better than you might think. I find I can type just fine, and the screen is at eye level.

Related tweet with more pics

Other ideas?

Know of other good hardware I should consider? Please post a comment!

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect, Microsoft MVP, and trains software developers internationally on front-end development practices. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Here’s a question I’ve heard a few times recently:

“What if we create a component library in React/Vue/Angular/whatever and a new component technology replaces it?”

That’s not a question of if. It’s a question of when. These technologies have become wildly popular, but they’re not the end game. Like all technologies, something better will eventually come along and replace them.

But that fact is largely irrelevant. Establishing a library of reusable components for your company today remains absolutely critical.

Here’s why.

Move Faster Today

Reusable components help your team move faster by creating higher level abstractions. Components eliminate decision fatigue by programmatically enforcing a standardized approach. Just consider an opinionated form TextInput component.

It can eliminate all the following decisions:

1. Should I put the label above the input or beside it?
2. Should I display validation errors to the right or below the input?
3. What color should the error be?
4. How should I mark required fields?
5. Should I validate required fields on blur or upon submit?
6. How much padding should I place between the label and the input?

The list goes on. These aren’t questions your designers and developers should be asking every time they create a new form.

Enforce Consistency

Reusable components enforce user interface consistency. Your company likely has many developers. Yet your job is to build an app that looks like it was built by one developer.

To do that, it’s critical to use reusable components. Copy/paste isn’t a design pattern. If designers and developers have the freedom to start from scratch again and again, your application will quickly become a patchwork of different looks, feels, and technologies.

Improve Performance

In a client side rendered app, every time you use a component you improve performance. Why? Because it minimizes the application’s bundle size and memory footprint. Using a component a second time requires no additional download, and hardly any extra memory.

Without a component library, your team is highly likely to include duplicate JavaScript that solves the same problems in slightly different ways which will bloat the bundle and slow performance. Even worse, they’re likely to grab another competing library and thus require users to download multiple full libraries that do the same thing.

Less Maintenance

More code leads to more maintenance. More maintenance leads to higher costs and more people which creates additional communication overhead that slows you down even further. Reusable components minimize the amount of code you need to create and maintain today.

Easier Updates Later

Finally, yes, eventually the component tech you’re using today is going to be legacy. But by creating a reusable component library today, you minimize the surface area that needs updated later.

It’s far easier to migrate a carefully componentized app because you can replace existing components one component at a time. That’s not so easy when your application is a patchwork of different technologies and patterns. Reusable components minimize the surface area you’ll need to update later.

Low Investment

A component library doesn’t actually require that much work. For instance, if you choose React, you need not, (and typically shouldn’t) start from scratch. There are literally dozens of mature component libraries to choose from and 100’s of standalone components as well.

Use a popular component library as your starting point and tweak it to your needs. Trust me, this need not take long and the benefits are significant.

Alternatively, you could choose to create plain CSS components as your foundation. An example of this approach is Stacks from StackOverflow. The advantage to this approach is twofold:

1. If you move to a new technology in the future, the plain CSS foundation that you’re using behind the scenes in your JavaScript components can be reused.
2. If your company is currently using multiple component approaches such as React, Angular, and/or Vue, then this CSS approach can be used as the foundation for all.

The disadvantage? You have to build your components from scratch so that they utilize your plain CSS component foundation.

My preference? Leverage an existing JavaScript component library as your foundation to minimize the amount of code you need to write to get rolling.

Summary

Don’t let the rapid innovation in JavaScript scare you away from investing in a reusable component library for your company. Yes, today’s technology will eventually be replaced, but change is the only constant in technology. For all the reasons above, reusable components are worth embracing today.

Looking for more details on how to get this done? I recently published “Creating a Reusable React Component Library” on Pluralsight. (free trial)

Looking for More on React? ⚛️

I’ve authored multiple React and JavaScript courses on Pluralsight.

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect, Microsoft MVP, and trains software developers internationally on front-end development practices. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Today many web apps are built using React, Angular, Vue, Ember, and others. These modern client-side rendered apps often call web APIs that are hosted on separate servers. This creates a problem: how do you configure your app to call the right API URL in each environment?

For example, during development, you may host the API locally at localhost:3000. In production, the API may be be hosted on some other server at api.mycompany.com. So you need your app to call localhost:3000 in development and api.mycompany.com in production. But how?

And the base URL is just one example of settings that may change per environment. You might choose to tweak other settings per environment for performance, security, or logging purposes. Some of the approaches below are applicable for these general environment-specific configurations as well. But for simplicity, this post focuses on techniques for configuring base URLs per environment.

I posted a poll on Twitter with a couple options:

Cory House 🏠 on Twitter

📊Poll: How do you configure your client-side rendered apps to call different API URLs in each environment? Example: Dev api runs on localhost:3002 Prod api is at https://t.co/8ZSpUMQi4m

Turns out, there are many ways to handle this. I received many insightful replies in the tweet thread. I’ve summarized eight options below. I’ve ordered these options (loosely) in the order that they should be considered. So, if you’re in a hurry, the options to consider first are at the top. 😀

Option 1: Host the API with the app

Simple. Just host the app and API from the same webserver, so relative URLs work everywhere. This avoids both the base URL issue as well as cross-origin problems.

When to consider it:

• Your API is consumed by a single app.
• You don’t need to scale your API and app separately, so hosting on the same server is practical.

Option 2: Environment-Specific Build

This approach honors the compile-time maxim:

“Never do at runtime what you can handle at compile time.”

With this approach, you typically use a continuous integration (CI) server to generate and deploy custom builds for each environment. This is a powerful, secure, and versatile approach, but it requires each developer to create and maintain a .env file on their machine. Here’s a great post with some tricks for making this pretty painless.

When to consider it:

• You’re comfortable configuring a CI server to automate the build and deployment process to assure reliability.
• You want to significantly alter the code deployed to production, such as removing code that is only used in non-production environments for performance or security reasons.
• You’re comfortable with the risk that comes along with deploying different code to production than the code you ran during development and QA.

Option 3: Runtime Configuration

With this approach, you configure your app for each environment by referencing the relevant configuration data upon startup (as opposed to upon build as discussed above). So unlike the approach above, with this approach the same code is deployed to all environments. The configuration data you pass in on startup customizes the app’s behavior.

There are a couple potential ways to pass environment configuration data in:

1. Command line config — Pass the config in when starting the app.
2. Environment config file — Populate a .env file in each environment and read from it upon startup. Here’s an example from the create-react-app docs, but the approach applies to any JavaScript app.

But how does your app get this info? There are a couple ways to do that, too:

1. Config file — Write the config data to a separate JavaScript file on app startup. Your app can import and read this file on startup.
2. Global in index.html — Write the config data to a global in index.html using your build tool. Again, here’s an example from the create-react-app docs, but the approach applies to any JavaScript app.

Admittedly, these approaches slightly change your code on startup based on the runtime configuration provided. But they’re different than option #2 above, because the same code is deployed to all environments.

When to consider it:

• You prefer to deploy the same code to all environments.

Option 4: Reverse Proxy

With this approach, you call the same relative URL in all environments. How does that work? Well, it’s the front-end web server’s responsibility to forward calls to the relevant API for each environment. There are multiple benefits to this approach:

1. Your URLs in all your API calls are clean, relative URLs. For example /user.
2. You can configure your front-end web server as a caching layer for added performance.
3. This approach supports switching back-end systems by simply re-configuring the proxy.

Eric Elliott on Twitter

@housecor I always use relative /api path. Then let the web servers reverse proxy that wherever it needs to point to. No code changes or conditional logic required.

When to consider it:

• You have the ability to configure the web server in all environments
• You’re interested in implementing a caching layer between your UI and your API.
• Your front-end web server can forward calls to your API server reliably and quickly. There is a performance cost to this approach, since your web server must pass requests on to another server.

Side note:

While we’re talking about proxies, another proxy approach worth mentioning is proxy middleware (this is a totally different approach than the reverse proxy discussed above).

With proxy middleware running on your local machine, requests are forwarded to a specified URL during development. For instance, if you’re a React developer, create-react-app has proxy support built in. It uses Webpack’s proxy middleware.

Here’s a solid overview of the proxy approach using React and Express.

However: Proxy middleware only solves the base URL problem in development. So use one of the other techniques in this post to handle other environments such as QA and production.

Option 5: Docker

With Docker you can deploy the UI and API as separate containers, but create a “LAN” that allows the containers to communicate as though they’re on the same network. This way, the base URLs don’t change in each environment. The containers run identically in all environments. And you can pass relevant environment variables into the containers in each environment. Look into Kubernetes or Docker Swarm for this approach.

When to consider it:

• You’re already invested in the Docker ecosystem.

Option 6: Environment Sniffing

With this approach, you use code to “sniff” 👃🏻 the current environment, typically by looking at the URL. For example, if the URL is http://localhost, you know you’re in development.

The benefit of this approach is simplicity. Developers don’t need to configure anything on their machine and you don’t need to monkey with CI server or web server configurations either.

When to consider it:

• You have a simple app that calls a small number of APIs.
• You don’t have a CI-server.
• Your company politics make it painful or impractical to implement the other options above.
• You’re not concerned about people potentially finding the URLs to your non-production environment. (For security, your non-production environment shouldn’t be accessible outside your corporate LAN/VPN anyway).

Option 7: Custom HTTP header

Configure the front-end web server to provide a custom HTTP header that contains the relevant client URL for the environment. The downside of this approach is your app has to make an HTTP call to this API first to determine what the relevant base URLs are for all environments.

When to consider it:

• I don’t recommend this approach, since it requires your app to make a round trip HTTP call before it can actually begin fetching data. I prefer one of the other approaches above.

Option 8: App Config Endpoint

With this approach, your app calls the same “app config” API at the same URL, for all environments. Your app calls this API first. The API call returns the relevant base URL in each environment (as well as potentially including other environment-specific settings). With this approach, you can potentially pass along with other relevant environment-specific config data.

When to consider it:

• I don’t recommend this approach either. It impacts load time, because the initial HTTP call to retrieve config data must complete before the app can actually get started retrieving desired data. Consider one of the other options above instead.

Summary

Create a build per environment via a CI server if you need true per-environment customization (#2 above). If you prefer deploying the same code to each environment, consider runtime configuration (#3 above) or a reverse proxy (#4 above).

Happy coding! ⌨️

Have other ways you handle this? Please chime in via the comments.

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect, Microsoft MVP, and trains software developers internationally on front-end development practices. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Disclaimer: BenQ gave me this monitor for free in exchange for this review. That said, as you’ll see these are my honest impressions.

As a software developer, I’ve run 2 or 3 monitors for years. But a few years ago I realized I preferred using a single display. The question is, what’s the perfect single display? I currently use a 24" Dell 4K in the office and a 27" Dell 4K at home. BenQ offered me their new EW3270U 32" 4K display with USB-C in exchange for writing an honest review.

Size

Wow, this thing is big. At 32", it’s large enough to run the native 3840x2160 resolution. Doing so creates a massive desktop with small, crisp text.

To give you a sense of how much real estate you get, you can easily split the screen into 4 pieces and have plenty of room in each window to work comfortably.

In fact, there’s enough real estate to comfortably display 6 windows!

However I find text at the native resolution too small for comfort. Most will find 2560x1440 more practical. This is still a sufficient width to comfortably run windows side-by-side. However, this resolution isn’t as sharp. Why? Because math. Since 2560x1440 isn’t evenly divisble by the native resolution, it requires scaling. So you have to sacrifice a bit of text clarity and performance for the increased real estate. MacOS even warns you that these intermediate resolutions may impact performance (due to scaling overhead):

To avoid scaling, you have to run either the native resolution or 1920x1080, which is conveniently 1/4 the native resolution, so scaling isn’t required.

I currently run both my 27" and 24" Dell 4K displays at 1920x1080 to avoid scaling. At 1920x1080, text is huge on this 32", but it’s also crisp and very easy on the eyes. Although this display’s PPI is only 140, the text looks about as sharp as my 27" and 24" 4K displays.

Stand

The stand is sturdy and tilts, but unfortunately lacks height adjustment, rotation, and cable management. The good news is the stand sits at a natural height for a traditional desk. My eyes sit in the upper third which is the recommended height. That said, I suspect many will attach this to a VESA mount.

Panel

There are three common LCD panel technologies: TN, VA, and IPS.

Here’s a summary:
“VA panels provide a good middle ground with better-than-IPS refresh rates and contrast levels, but have worse viewing angles and color production, although generally still better than TN. Response times are VA’s largest downfall, though, being slower than IPS and its variants and TN.” — Michael Kerns

More here.

This is a VA panel, so the viewing angles and color fidelity aren’t as good as my IPS Dell 27", but the refresh rate and contrast is better. I prefer IPS panels, but this is a solid VA panel with a subtle matte finish that is effective at handling glare yet subtle enough that it doesn’t seem to degrade the picture.

Unfortunately, at my standard viewing distance, the colors on the edges fade slightly compared to the middle. And that’s the core problem with using a VA panel at this size: The edges are far enough away that the viewing angle limitations are visible on the sides — even when viewed from the sweet spot.

On my IPS displays, colors and brightness are uniform.

That said, unless you’re doing image critical work such as editing photographs, this is a minor annoyance in most real world cases. It’s unlikely to bother you if you’re used to TN or VA panels.

Design

This BenQ design is clean enough, but not as modern as some competitors. For example, my Dell U2718Q has a panel that is flush with the bezel (rather than inset), and bezels that are less than half as wide as the BenQ display’s. And given the BenQ’s bezel size, it’s disappointing a webcam isn’t included.

I/O

I was excited to see this monitor provides USB-C, and the included USB-C cable displays at 60hz as expected. However, there are two notable issues with this monitor’s USB-C implementation:

1. No power is passed over USB-C. This is a big disappointment given competitors like LG do so. Other BenQ displays provide power as well. Without USB-C charging, you can no longer enjoy a single cable hookup experience.
2. No daisy chaining support. You can’t connect another display to the back of this one. Again, this is supported on other USB-C monitors and some BenQ displays.
3. There are no USB inputs, which greatly reduces the usefulness of the USB-C input.

Bottom-line, this monitor’s USB-C input is redundant. The DisplayPort 1.4 port is also capable of displaying 4K@60hz, so one could simply buy a USB-C to Displayport cable if they have a USB-C machine and get the same experience. So unfortunately, I see no benefit to this monitor including USB-C.

Two HDMI inputs are also included, as well as a headphone jack.

Speakers

The included 2 watt speakers get loud enough, but sound thin. My Macbook Pro’s built in speakers are clearer and equally loud. Shoot, even my iPhone 7’s speaker sounds notably better and reproduces a greater frequency range. That said, most monitors don’t include speakers, so having this in a pinch is a nice touch.

Eye Care

This monitor also includes BenQ’s B.I.+ (Brightness Intelligence Plus), which adjusts the backlight and color temperature based on the environment. This feature works well and I’ve found it useful. I often work in a dimly lit room at night and very bright room with many windows during the day. This display is looks great in both extremes and I don’t have to fiddle with any settings. And much like my MacBook Pro, the brightness changes are gradual so they’re not jarring. Turn out the lights and it subtly dims over a short period. Nice.

BenQ promotes other eye care features on this monitor including a “low blue light” setting which filters out blue light that can cause eye strain. The effect is subtle, but I will say the display is easy on the eyes and much more pleasant to look at than many harsh, bluish LCDs I’ve seen. Filtering blue light should help foster sleep in the evenings too.

Other Unique Features

This is an HDR display. I streamed 4K HDR content from Netflix and was very impressed with the results — it looks excellent. You can press the dedicated HDR button on the front of the panel to enable emulated HDR mode, which produces a brigther, bluer picture. This works well for video content. A second press on the front panel button enables the aforementioned B.I.+ feature.

“Super Resolution” claims to enhance the resolution of low quality images. I found it seems to operate like a sharpness control on a TV. Like my TV, I prefer to keep sharpness turned off since it creates visible artifacts in an effort to enhance edges.

“Smart Focus” grays out a portion of your screen so you can focus on a specific area.

Price

At $699, this display isn’t cheap. 32" 4K displays are significantly pricier than 27" competitors. The only 32" 4K USB-C competitor I’ve found is the LG 32UD99 which is $999. For the extra $300, you get an IPS panel, smaller bezels, a height adjustable stand that rotates vertically, USB ports, more powerful speakers, and 60 watts of power over USB-C. But the LG display lacks the unique eye care features offered on this BenQ.

Conclusion

So who is this for? This monitor is a worth considering if one or more of these apply to you:

• You want a massive desktop for multi-tasking and are okay with small text. 32" is arguably the bare minimum size for running native 4K.
• You want to run two windows side-by-side at 2560x1440 and are willing to take a slight hit in text sharpness and performance due to scaling.
• You want big, beautiful, crisp text with high contrast. This monitor touts unique eye care features, but perhaps the most significant eye care feature is the ability to display crisp content at a very easy-to-read size when run at 1920x1080.
• You work in various lighting conditions and would thus appreciate the B.I.+ feature.
• Your use cases don’t require an IPS panel’s superior viewing angles and color fidelity.
• The lack of integrated USB ports doesn’t effect you because you’re using a desktop or your laptop has sufficient ports built in.

If any of these points apply to you, the BenQ EW3270U is worth considering.

React is a component library. So React makes it easy to break your UI down into composable pieces. The question is, how granular should the pieces be?

Let’s consider a specific example that I explored in a previous post.

Imagine your team just deployed a ToDo app, built in React. A month later, another team in your company wants to run your ToDo app within their invoice app, also built in React.

So now you need to run your ToDo app in two spots:

1. By itself
2. Embedded within the invoice app

What’s the best way to handle that? 🤔

To run your React app in multiple spots, you have three options:

1. iframe — Embed the todo app in the invoice app via an <iframe>.
2. Reusable App Component — Share the entire todo app via npm.
3. Reusable UI Component — Share the todo app’s markup via npm.

Let’s discuss the merits of each approach.

Approach 1: iFrame

The easiest and most obvious approach is to use an iframe to frame the ToDo app into the invoice app.

But leads to multiple issues:

1. If the two apps display the same data, you risk them getting out of sync.
2. If the two apps use the same data, you end up making redundant API calls to fetch the same data.
3. You can’t customize the iframed app’s behavior.
4. If a different team owns the framed in app, when they push to production, you’re instantly affected.

Bottom-line: Walk way. Avoid iframes.

Approach 2: Reusable App Component

Sharing your app via npm instead of an iframe avoids issue #4 above, but the other issues remain. API, auth, and behavior are all baked in. So I don’t recommend sharing full apps via npm either. The level of granularity is too high, so the user experience suffers.

Approach 3: Reusable UI Components

I recommend a more granular approach using two flexible building blocks:

1. “Dumb” React components (Just UI. No API calls inside.)
2. API wrappers

“Dumb” React components are configurable, unopinionated, and composable. They’re reusable UI. When consuming a “dumb” component like this, you are free to provide the relevant data or specify the API calls the app should make.

However, if you’re going to compose “dumb” components, you need to wire up the same API calls for multiple apps. This is where API wrappers come in handy. What’s an API wrapper? It’s a JavaScript file full of functions that make HTTP calls to your API. My team creates API wrappers. We use Axios behind the scenes to make the HTTP calls.

Imagine you have a user API. Here’s how to create a user API wrapper:

1. Create a JS file with public functions like getUserById, saveUser, etc. Each function accepts the relevant parameters and uses Axios/Fetch to make HTTP calls to your API.
2. Share the wrapper as an npm package called userApi.

Here’s an example.

On my team, we share our React components and API wrappers as private packages on npm, but Artifactory is a nice alternative.

These Lego blocks give us the foundation for quickly building new solutions out of reusable pieces.

A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements. — Wikipedia

So ideally, your “dumb” reusable UI component is composed of other reusable components, also shared on npm!

With reusable React components and API wrappers published to npm, it’s trivial to build something awesome.

It’s like snapping Lego pieces together. 👍

I explore the merits and downsides of the approaches above in more detail here. And I recently published a comprehensive course on Creating a Reusable React Component Library on Pluralsight. 🎉

Have a different approach you enjoy? Chime in via the comments.

Looking for More on React? ⚛️

I’ve authored multiple React and JavaScript courses on Pluralsight (free trial).

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect, Microsoft MVP, and trains software developers internationally on front-end development practices. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

I previously owned a 2015 13" MacBook Pro, but purchased a 15" Macbook Pro TouchBar in Nov. 2016. I posted an initial review after one week.

The results after one year? It’s been a mixed bag, but here’s the tl;dr:

There are keyboard and reliability issues, but all considered I prefer it over the 2015.

The Good

Superb screen — For me, this is the most compelling reason to choose a Mac. I hear Apple has a patent on their screen glare reduction approach, and it shows. Every other laptop I’ve seen is hard to use in bright lighting because it’s like a black mirror — this issue is even worse on touchscreen machines.

On the new MBP, reflections are muted. Plus, the new MacBook screen is notably brighter — enough so that I can work sitting in the sun and easily read it. I love working outdoors with a hat on to keep the sun out of my eyes, so that’s a huge win. The result: I enjoy using the new MacBook Pro in my hammock. 🌴

USB-C — Being able to plug any peripheral in from either side is wonderful. No more awkward cable routing. And cords are effectively a foot longer when you know you can plug in on the near side. I dock my machine with two cables. I use a Monoprice USB-C dongle to connect Gigabit Ethernet, power, and three different USB peripherals. I use a second USB-C to Displayport cable to run a Dell 27" 4K Monitor at 60hz. Yes, I prefer running a single monitor.

Side note, ❤️ this monitor:

Cory House 🏠 on Twitter

Just upgraded to 27" 4K Dell. Love it! Compared to old 24" 4K: -HDR -Richer colors, contrast -Flush, small bezel -Uses only 30W vs 90W! 👍

When traveling, I use Apple’s dongle to display on projectors via HDMI.

I haven’t missed MagSafe for two reasons:

1. I typically only plug in when at a desk where MagSafe is largely irrelevant.
2. USB-C dongles pass power through, so there’s now one less thing to connect. 👍

With two USB-C connections, I’m docked.

Sufficient battery life — Battery life hasn’t been a problem. It seems similar to my old 13" as long as I avoid running the screen at high brightness. I typically get around 5 hours, though I often work outside or with the screen brightness cranked up. If you keep the screen brightness down, the battery life is seriously impressive:

Cory House 🏠 on Twitter

New 15" MBP battery life is quite impressive in low light. After 5 hrs of reading &amp; coding on a flight, got off with 74% battery life left!

TouchID is (finally) awesome — This was initially unreliable, but an OS update made it rock solid and fast as the iPhone. Super handy.

Larger Trackpad FTW — I’ve grown to love the new giant trackpad. I initially had issues with palm rejection, but an OS update fixed that. I tried using a 2015 MacBook Pro recently and the trackpad felt too small. I found myself hitting the edges. I was initially skeptical, but the giant trackpad is a win. And it’s natural that it’s the same size as my external Magic Trackpad 2.

Great packaging — After a year of heavy travel, I have no regrets moving from a 13" to the new 15". The 15" is easily portable. I recently tried a 2015 15" and the difference in thickness and weight was instantly noticable. The new 15" is the first 15" that’s thin and light enough for me to enjoy traveling with it.

Cool and quiet — The fan virtually never comes on. The machine is consistently cool to the touch.

Great speakers — The speakers continue to impress, though I typically wear Airpods for music and web-based meetings.

Fast — Notably faster than my old 13". Likely attributable to the faster SSD.

The Bad

Polarizing keyboard — Some rave about the new keyboard, but I’ve never warmed to it. It’s a step backward to me. The key action on the old keyboard is more comfortable and reliable. The travel is so shallow that I have to deliberately hit the keys gently or my fingertips hurt. The spacebar became unresponsive on 3–4 occasions. In each case, I fixed it by sliding my fingernail around the key. I assume debris was impeding key travel.

At one point there was something under the spacebar that impeded the key, but slapping the key and tilting the machine around fixed it.

Thankfully, I rarely use laptop keyboards. I prefer to keep the screen at eye-level via The Roost for better ergonomics.

Cory House 🏠 on Twitter

Pro tip: Bring an HDMI cable when traveling. Hotel TV makes a good 2nd monitor in a pinch! (2 displays required for @pluralsight recording)

When traveling, I typically use the Apple Magic Keyboard 2, which has keys that feel like the old 2015 Macbook Pro. 👍 When home, I use the Microsoft Sculpt. I use a Magic Trackpad 2 with both keyboards so I always have the same gestures available as when using the laptop directly.

Touchbar = meh — It’s customizable, which is cool, but I typically use the machine with an external keyboard, so I rarely use the TouchBar. I would happily buy a machine with plain F keys and save the money and battery life.

Stability — The machine is rock solid when running alone. But a small portion of the time, the machine will reboot upon connection to a USB-C dock while closed. I’ve learned to dock with the clamshell open and it works fine. Occasionally, the separate USB-C to monitor connection fails to display. In those cases, I plug into a different USB-C port and it works. Thankfully, both are rare, so I can live with it.

Build quality issue — My machine was sporadically making popping noises near the hinge. Many have reported the problem. I reported it to Apple and the experience was very smooth. They shipped me a box so I could ship the machine in, and I had the machine back in about a week with the issue resolved under warranty. They even paid for next day air to return my device. This is the first quality issue I’ve had with an Apple product. To their credit, it was handled well.

Summary

The keyboard and docking stability are the key annoyances for me. I have workarounds for both, so given all the other wins, I’ve decided:

I’m keeping it.

Cory House is the author of many courses on Pluralsight, and principal consultant at reactjsconsulting.com. He is a Principal Software Engineer at Cox Automotive, Microsoft MVP, and trains software developers internationally on software practices. Catch Cory on Twitter as @housecor.

There are three popular ways to handle types in React: PropTypes, TypeScript and Flow. This post is about PropTypes, which are currently the most popular.

Cory House 🏠 on Twitter

📊 For enforcing types in React, I typically use... #react RT's appreciated

Since PropTypes provide type warnings at runtime, it’s helpful to be as specific as possible.

• Component accepts an object? Declare the object’s shape.
• Prop only accepts a specific list of values? Use oneOf.
• Array should contain numbers? Use arrayOf.
• You can even declare your own types. AirBnB offers many additional PropTypes.

Here’s a PropType example:

In real apps with large objects, this quickly leads to a lot of code. That’s a problem, because in React, you’ll often pass the same object to multiple components. Repeating these details in multiple component files breaks the DRY principle (don’t repeat yourself). Repeating yourself creates a maintenance problem.

The solution? Centralize your PropTypes.

Here’s How to Centralize PropTypes

I prefer centralizing PropTypes in /types/index.js.

I’m using named imports on line 2 to shorten the declarations. 👍

And here’s how I use the PropType I declared above:

I use a named import to get a reference to the exported PropType declaration on line 2. And I put it to use on line 13.

Benefits:

1. The centralized PropType radically simplifies the component’s PropType declaration. Line 13 just references the centralized PropType, so it’s easy to read.
2. The centralized type only declares the shape, so you can still mark the prop as required as needed.
3. No more copy/paste. If the object shape changes later, you have a single place to update. 🎉

Here’s a working example on CodeSandbox.

Extra Credit: Generate Your PropTypes

Finally, consider writing some custom code to generate your PropType declarations from your server-side code. For example, if your API is written using a strongly typed language like C# or Java, consider generating your PropType declarations as part of your server-side API build process by reading the shape of your server-side classes. This way you don’t have to worry about keeping your client-side PropTypes and your server-side API code in sync. 👍

Side-note: If you know of a project that does this for any server-side languages, please reply in the comments and I’ll add a link here.

Edit: You can convert JSON into PropTypes using transform.now.sh. 🎉

Summary

1. Declare your PropTypes as explicitly as possible, so you know when you’ve made a mistake.
2. Centralize your PropTypes to avoid repeating yourself.
3. If you’re working in a strongly typed language on the server, consider generating your PropTypes by reading your server-side code. This assures your PropTypes match your server-side types.

Looking for More on React? ⚛️

I’ve authored multiple React and JavaScript courses on Pluralsight (free trial).

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Update 5/31/19: React 16.8 added Hooks, which mean you can use functional components for nearly everything! 🎉 Function components are the future of React. So bottom-line, use functional components for future development. That said, the tradeoffs below apply for older codebases where Hooks aren’t an option. Happy coding!

I’m spending the week consulting a team in Seattle to help accelerate their transition to React. Today, we discussed the 8 key decisions to make to standardize React development.

I shared 9 reasons I’m a fan of functional components. One response surprised me:

“Let’s forbid using functional components.”

Woah, really? We discussed the issue at length. Here’s why.

1. Conversion Hassle

Functional components don’t support state, refs, or lifecycle methods. They can’t extend PureComponent either. Sometimes, you’ll create a functional component only to realize that you need one of these class-only features later. In these situations, it’s a hassle to manually convert to a function into a class.

Edit: Instead of converting to a class, you can enhance existing functional with lifecycle methods, state, and more via recompose.

2. Messy Diffs

After you’ve finished the conversion, the diff is noisy. Even a trivial one-line change results in a multi-line code review.

Here’s an example of converting a functional component to a class so that it can be declared a PureComponent.

If this component were declared as a class from the start, the true intent of the commit would be crystal clear — it would require a 4 character change:

Conversion obscures the component’s history by creating the illusion that the component has been largely rewritten when in fact you may have made a very trivial change. The person who does the conversion will be “blamed” for writing many lines that they merely changed for conversion reasons.

3. Minor Signal to Noise Differences

Compare a minimal class to a function, and the differences are minor. Remember, constructors are optional without state.

Correction: Oops! I forgot the functional style can be a one-liner with a simple arrow function:

const Hello = ({greeting, firstName}) => <div>{greeting} {firstName}</div>

4. Inconsistency

Function and class components look different. This inconsistency can slow developers down as they shift between the two styles.

• In classes, you say this.props, in functions, you say props.
• In classes, you declare a render function. In functions, you don’t.
• In classes, you destructure at the top of render. In functions, you destructure in the function’s argument list.
• In classes, you declare default props below the component (or via class properties if you’re willing to use a stage-3 feature). In functions, you declare default props using default arguments.

These subtle differences add friction for new devs, and the context switching leads to mistakes for experienced devs too.

5. Classes Are Familiar to OO Developers

Yes, JavaScript’s classes are certainly different than Java and C# classes. But anyone working in OO-land on the server is likely to find this simple rule easy to understand:

“A React component is a class that extends React.Component.”

Adding a nuanced conversation about how and when to use plain functions adds confusion for OO devs who are already accustomed to being required to use classes for everything. Now I’m not saying this mindset is healthy — the React community fosters more of a functional mindset. But, one must acknowledge that functional components create mental-model friction for OO devs.

6. No Performance Benefits, Yet

While the React team has alluded to the chance that functional components will be faster or more efficient in the future, that’s not the case yet. So one could argue functional components are currently a premature optimization.

And since functional components require conversion to a class to implement today’s performance tweaks like shouldComponentUpdate and PureComponent, they’re actually more of a hassle to optimize for performance today.

Update: With React 16.6+, you can declare “pure” functional components via React.memo.

7. Yet another decision

Finally, JavaScript developers already have a ridiculous number of decisions to make. Banning functional components eliminates a decision: Always create a class.

Summary

I’m still a fan of functional components. But now I recognize they’re not necessarily a slam dunk for everyone. So, as usual, consider the tradeoffs. 👍

See other downsides or benefits? Chime in below.

Looking for More on React? ⚛️

I’ve authored multiple React and JavaScript courses on Pluralsight (free trial).

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

React was open-sourced in 2013. Since then, it has evolved. As you search the web, you’ll stumble across old posts with dated approaches. So, here are eight key decisions your team needs to make when writing React components today.

Decision 1: Dev Environment

Before you write your first component, your team needs to agree on a dev environment. Lots of options…

Cory House 🏠 on Twitter

📊Poll: What boilerplate do you typically use for React development today? #react #reactjs

Sure, you can build a JS dev environment from scratch. 25% of React devs do just that. My current team uses a fork of create-react-app with additional features such as a realistic mock API that supports CRUD, a reusable component library, and linting enhancements (we lint our test files too, which create-react-app ignores). I enjoy create-react-app, but this tool will help you compare many compelling alternatives. Want to render on the server? Check out Gatsby or Next.js. You can even consider using an online editor like CodeSandbox.

Decision 2: Types

You can ignore types, use prop-types, use Flow, or use TypeScript. Note that prop-types was extracted to a separate library in React 15.5, so older posts will show imports that don’t work anymore.

The community remains divided on this topic:

Cory House 🏠 on Twitter

📊 For enforcing types in React, I typically use... #react RT's appreciated

I prefer prop-types because I find it provides sufficient type safety in React components with little friction. Using the combination of Babel, Jest tests, ESLint, and prop-types, I rarely see runtime type issues.

Decision 3: createClass vs ES Class

React.createClass was the original API, but in 15.5, it was deprecated. Some feel we jumped the gun moving to ES classes. Regardless, the createClass style has been moved out of React core and relegated to a single page called “React without ES6” in the React docs. So it’s clear: ES classes are the future. You can easily convert from createClass to ES Classes using react-codemod.

Decision 4: Class vs Functional

You can declare React components via a class or a function. Classes are useful when you need refs, and lifecycle methods. Here are 9 reasons to consider using functions when possible. But it’s also worth noting that there are some downsides to functional components.

Decision 5: State

You can use plain React component state. It’s sufficient. Lifting state scales nicely. Or, you may enjoy Redux or MobX:

Adam Rackis on Twitter

No flame wars please - honestly curious where the React community is these days. For new Pr/React projects, I use ___ for state management.

I’m a fan of Redux, but I often use plain React since it’s simpler. In my current role, we’ve shipped about a dozen React apps, and decided Redux was worth it for two. I prefer shipping many, small, autonomous apps over a single large app.

On a related note, if you’re interested in immutable state, there are at least 4 ways to keep your state immutable.

Decision 6: Binding

There are at least half a dozen ways you can handle binding in React components. In React’s defense, this is mostly because modern JS offers many ways to handle binding. You can bind in the constructor, bind in render, use an arrow function in render, use a class property, or use decorators. See the comments on this post for even more options! Each approach has its merits, but assuming you’re comfortable with experimental features, I suggest using class properties (aka property initializers) by default today.

This poll is from Aug 2016. Since then, it appears class properties have grown in popularity, and createClass has reduced in popularity.

Cory House 🏠 on Twitter

How do you handle binding in #reactjs today? Examples: https://t.co/z7OKxe39VA

Side note: Many are confused about why arrow functions and bind in render are potentially problematic. The real reason? It makes shouldComponentUpdate and PureComponent cranky.

Decision 7: Styling

Here’s where the options get seriously intense. There are 50+ ways to style your components including React’s inline styles, traditional CSS, Sass/Less, CSS Modules, and 56 CSS-in-JS options. Not kidding. I explore React styling approaches in detail in the styling module of this course, but here’s the summary:

See why there is so much fragmentation in React’s styling options? There’s no clear winner.

My current team uses Sass with BEM and are happy enough, but I also enjoy styled-components.

Decision 8: Reusable Logic

React initially embraced mixins as a mechanism for sharing code between components. But mixins caused issues and are now considered harmful. You can’t use mixins with ES class components, so now people utilize higher-order components and render props (aka function as child) to share code between components.

Kent C. Dodds on Twitter

POLL for devs writing #ReactJS]: Which do you prefer? HOC: https://t.co/aczxcPUd8j Render Props: https://t.co/2haYUuGK7z

Higher-order components are currently more popular, but I prefer render props since they’re often easier to read and create. Michael Jackson recently sold me with this:

And that’s not all…

There are more decisions:

• Will you use a .js or .jsx extension?
• Will you place each component in its own folder?
• Will you enforce one component per file? Will you drive people nuts by slapping an index.js file in each directory?
• If you use propTypes, will you declare them at the bottom, or within the class itself using static properties? Will you centralize your PropTypes? Will you declare propTypes as deeply as possible?
• Will you initialize state traditionally in the constructor or utilize the property initializer syntax?

And since React is mostly just JavaScript, you have the usual long list of JS development style decisions such as semicolons, trailing commas, formatting, and event handler naming to consider too.

Choose a Standard, Then Automate Enforcement

And all this up, and there are dozens of combinations you may see in the wild today.

So, these next steps are key:

1. Discuss these decisions as a team and document your standard.

2. Don’t waste time manually policing inconsistency in code reviews. Enforce your standards using tools like ESLint, eslint-plugin-react, and prettier.

3. Need to restructure existing React components? Use react-codemod to automate the process.

Other key decisions I’ve overlooked? Chime in via the comments.

Looking for More on React? ⚛️

I’ve authored multiple React and JavaScript courses on Pluralsight (free trial).

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Three patterns for running the same app in multiple spots

Imagine your team just deployed an amazing todo list app. A month later, another team in your company wants to run your todo app within their invoice app.

So now you need to run your todo app in two spots:

1. By itself
2. Embedded within the invoice app

What’s the best way to handle that? 🤔

To run an app in multiple spots, you have three options:

1. iframe — Embed the todo app in the invoice app via an <iframe>.
2. Reusable App Component — Share the entire todo app.
3. Reusable UI Component — Share only the todo app’s markup.

Option 2 and 3 are typically shared via npm for client-side apps.

In a hurry? Here’s the summary.

Let’s explore the merits of each approach.

Option 1: iFrame

With an iframe, you can compose two apps together by placing the “child” app in an iframe. So in our example, the invoice app would embed the todo app via an iframe. Easy. But not so fast…

When is an iframe a good fit?

1. Incompatible tech — If the apps you’re composing use incompatible technologies, this is your only option. For example, if one app is built in Ruby and the other in ASP.NET, an iframe allows the two apps to display side-by-side, even though they are actually incompatible and hosted separately.
2. Small, static dimensions - The app you’re framing in has a static height and width. Dynamically resizing iframes is doable, but adds complexity.
3. Common authentication story - An iframed app shouldn’t require separate authentication. Separate authentication can lead to clunky interactions as the framed app may prompt for separate credentials or timeout at a different time than the hosting app.
4. Runs the same way everywhere — With an iframe, the framed app will run the same way in each spot where it’s framed in. If you need significantly different behavior in different contexts, see the other approaches below.
5. No common data — With an iframe, the composed applications should avoid displaying the same data. Framing an app can lead to duplicate, wasteful API calls and out-of-sync issues between the framed app and its parent. Data changes in the iframe must be carefully communicated to the parent and vice-versa, or the user will see out-of-sync data.
6. Few inter-app interactions — There should be very few interactions between the hosting app and the iframed app. Sure, you can use window.postMessage to pass messages between the iframe and the hosting app, but this approach should be used sparingly since it’s brittle.
7. A single team supports both apps — With iframes, the same team should ideally own and maintain both the parent app and the framed app. If not, you must accept an ongoing coordination relationship between the teams that support the applications to assure they remain compatible. Separate teams create an ongoing risk and maintenance burden to maintain a successful and stable integration.
8. Only need to do this once — Due to the point above, you should only iframe an app once to avoid creating a significant maintenance burden. The more times an app is framed, the more places you risk breaking when you make changes.
9. Comfortable with deployment risks — With an iframe, you must accept the risk that a production deploy of the framed application may impact the parent app at any time. This is another reason having the same team support both the parent and framed app is useful.

Option 2: Share App Component

Node’s package manager, npm, has become the defacto way to share JavaScript. With this approach, you create an npm package and place the completed application inside. And it need not be public — you can create a private npm package on npm too.

The process for creating a reusable component library is beyond the scope of this post. I explore how to build your own reusable component library in “Building Reusable React Components”.

Since you’re sharing the entire app, it may include API calls, authentication concerns, and data flow concerns like Flux/Redux, etc. This is a highly opinionated piece of code.

When is the reusable app component approach a good fit?

1. Compatible tech — Since you’re sharing a reusable component, the parent app needs to be compatible. For instance, if you’re sharing a React component, the parent app should ideally be written in React too.
2. Dynamic size — This approach is useful if your app’s width/height are dynamic so it doesn’t fit well in a statically sized frame.
3. Common authentication story — The two applications should ideally utilize the same authentication. Separate authentication can lead to clunky interactions as each app may prompt for separate credentials or timeout at a different time.
4. You want the app to run the same way everywhere — Since API, authentication, and state management are built in, the app will operate the same way everywhere.
5. No common data — The two applications mostly work with separate data. Displaying apps side-by-side can lead to duplicate, wasteful API calls as each app makes requests for the same data. It can also lead to out-of-sync issues between the two apps. Data changes in one must be carefully communicated to the other, or the user will see out-of-sync data between the two apps.
6. Few inter-app interactions — There should be few interactions between the two apps. Sure, you can use window.postMessage to pass messages between them, but this approach should be used sparingly since it’s brittle.
7. A single team supports both apps — With this approach, ideally the same team owns and maintains both apps. If not, you must be willing to accept an ongoing coordination relationship between the teams that support the two applications to assure they remain compatible. Separate teams create an ongoing risk and maintenance burden to maintain a successful and stable integration.

Option 3: Share UI Component

This option is similar to option #2 above, except you share only the markup. With this approach, you omit authentication, API calls, and state management so that the component is basically just reusable HTML.

Popular examples of simple components like this include Material-UI and React Bootstrap. Of course, a reusable app component has more moving parts, but it operates on the same idea.

Before we discuss the merits of this approach, let me address a common question: “Should my reusable components embed API calls and auth?”

My take? Avoid embedding API, auth, and state management concerns in reusable components.

Here’s why:

1. It limits reuse by tying the front-end to a specific API, auth, state management story.
2. Often, separate developers/teams manage the UI and API. Embedding API calls in a reusable component couples the UI team and the API team together. If one side changes, it impacts the other, which creates an ongoing coordination overhead and maintenance burden.

But yes, this does mean each time someone uses your reusable component, they have to wire up the API calls and pass them in on props.

When is the reusable UI component approach a good fit?

1. Compatible tech — Since you’re sharing a reusable component, the parent app needs to be compatible. For instance, if you’re sharing a React component, the parent app should be written in React too.
2. Dynamic size — This approach is useful if your app’s width/height are dynamic so it doesn’t fit well in a statically sized frame.
3. Different authentication stories — Since this approach is basically just reusable HTML, the apps you want to compose can have different auth stories, or the auth story can differ in each place the component is used.
4. Different behaviors in each use case — With this approach, you can reuse a front-end, but call different APIs in each use case. Each copy of the front-end can operate completely differently. You can set different props and hit different APIs in each use case to tailor behavior as needed.
5. Common data — With this approach, the UI you’re composing can utilize and display the parent app’s data. It’s a single, cohesive app. This avoids duplicate API calls and out-of-sync issues, saves bandwidth, and improves performance.
6. Many cross-app interactions — If there are significant interactions and shared data between the applications, this approach assures that the two applications feel like a single cohesive experience…because this approach creates a single, cohesive app.
7. Discoverability is desirable — You want to publicize the existence of a rich, reusable front-end as a component. You can place this component in your reusable component library and document the props it accepts so that others can easily find and reuse it in different contexts.
8. Multiple use cases— You plan to deploy this front end in many places. This approach is more flexible than the other approaches since you’re just sharing a highly configurable front-end.
9. Separate UI and API teams — If you have a separate UI team, tying the UI to the API via the other approaches is unattractive due to the aformentioned coordination overhead. With this approach, you control when to update the npm package. You can deploy a new version of the reusable front end when desired, on a per app basis.

Summary

As usual, context is king. In most cases, I recommend approach #3, but each has valid use cases. Have another way to handle this? Please chime in via the comments.

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.