This article is a mix of arguments, reality checks and a code solution at the end. Its focus: device (touch/desktop) driven code split in React with no backend. Often the road leading to an actual implementation is long and bumpy - priorities, design, budget, colleagues with their own views, talking in different languages. These obstacles are challenging and usually take more energy to deal with than just coding. For that reason they deserve a separate preface here. Jump to the ( ) if this is what you are looking for, otherwise let's continue. code section Conditionally import and render components It would be helpful if you already know what code splitting is. If not yet, the "Code Splitting" writeup in the React docs is a good start. Reality Check Many companies today prefer to build their web apps/sites targeting both touch and desktop devices, but would rather not invest in a separate mobile app. Chiefs may not admit it, but the reasons spin around: Building for the browser is fast and cheap. No need to involve the backend. Prizing "mobile first", but don't really align with that principle. Technical impediments to deliver a mobile app to the store. No budget. Working in the browser is fast and reliable. There are many static site generators ( , , ) to support website creation with no backend knowledge required. principles and tools make production deployments of a product easier than ever. Such tools are capable of bringing the "mobile first" concept to life, though it still remains wishful thinking. Gatsby Nextjs Docusaurus Jamstack At the same time publishing a standalone mobile app to some app stores may turn into a nightmare. Read about fx. In contrast, javascript devs can quickly mockup a mobile version with the help of Chrome tools, so why hire an iOS/Android guy? the Hey saga All valid points and to add more, often you as a frontend professional won't get the chance to influence the final decision (especially in big companies). It is to be taken by product, marketing or finance teams. Native app or web app... Let's assume a decision is taken and you are left with no choice - . a web app must be delivered (for desktop and mobile users) If You Must Code Split Splitting react apps touch/desktop wise can be tricky if you have to do it in the frontend. Things to be considered: 1️⃣ account for touch and desktop devices ( to serve each app) when 2️⃣ decide on the split starting point ( in the code) where 3️⃣ import only app specific components ( to implement it) how An answer to these three questions is important since maintainability, time, team motivation and other aspects very much depend on it. When a Device Is Considered Touch 1️⃣ Usually you modify component's css to account for mobile devices. Perhaps the following { : ; : ;
  ...
} @ (max-width: ) { { : ; : ;
    ...
  }
} .TopBar height 60px background-color #fff /* Mobile */ media 768px .TopBar height 100px background-color #ccc works well for you most of the time. Same component, but with different appearance based on browser's width. There is no problem with this approach and very often it is enough. Now one may argue that is sufficient to properly tell if a user is on a mobile device. Probably not. May be something like that is more accurate: max-width: 768px @ (pointer: coarse) and (hover: none) {
  ...
} media Consider it when deciding on the criteria for serving your mobile web app. You can read more about interaction media features and their potential to determine device capabilities. Challenges arise when your company starts getting more serious about mobile users ("mobile first"). This could happen due to a separate strong design/UX and product teams being formed. In this reality your desktop and mobile websites/apps may end up drastically different. Business logic, pages, interactions and overall appearance are now unalike. Two independent versions of the same software. How does that translate in the React's language? For sure you won't be able to reuse every single component in both apps (touch and desktop). Same components/pages will require different data sets and behave non-identically (javascript logic). Others will be completely unique per app. Interactions and data (javascript) need to be considered along with styling (css). In that case css adjustments as the one above may no longer be sufficient. This is where a proper split in the frontend must be done and it can't reside in your .css files alone. Where to Split the App 2️⃣ It really depends. You have a few options considering requirements and design. is to split the app in its root. Maybe you have or just where page components are rendered based on the URL path. - split individual components. It is a good choice if pages for mobile and desktop are the same (or very similar), but some child components differ. You can also pick the of using media queries in the css. One PageRouter.js App.js Second option third option Split in the App's Root This approach makes sense if your mobile and desktop apps are very different - separate pages, behavior, data and business logic in components. Let's say there is a product details page ( ) on touch which doesn't exist in your desktop site. It displays detailed product information that otherwise would be part of when viewing on PC. On a phone, though, it might be too "noisy" to present so much data in a single page. <ProductDetails /> <Products /> -- src
   |-- components
   |-- pages
   |   |-- touch
   |   |   |-- Products.js
   |   |   |-- ProductDetails.js
   |   |-- desktop
   |   |   |-- Products.js
   |   |-- common
   |       |-- Checkout.js
   |-- App.js See a in Codesandbox. working example Why is this structure OK? More control You can look at and folders as two separate apps, allowing for full control over their content. /touch /desktop Easier maintenance Most pages in your app will be common - same names component-wise, but implementing app specific logic, which is great for maintenance. Bug fixing in isolation Having a bug in the products page on touch tells you that the cause is probably in . Fixing it there ensures your desktop page won't be affected. touch/Products.js Less side effects Few more buttons for mobile or a dropdown on desktop? You can feel more comfortable implementing feature requests like that next time. Adequate team collaboration Implementing a products page means you have to do it for each app (two components). With the folder split above, it's easy to divide the work within the team without stepping on each other's toes. Split on Component Level Root level code split is often supplemented by splitting the folder in a similar way. On the other hand, sometimes your desktop and mobile apps won't be very different. Only a few components deep in the tree may have an unalike data model or behavior. . /components If you find yourself in any of these cases it might be useful to do a split per component -- src
   |-- components
   |   |-- touch
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- desktop
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- common
   |       |-- Footer.js
   |       |-- Footer.css
   |-- pages
   |-- App.js component has some data/behavior differences that require you to implement it separately for each app. In the same time folder still contains all shared components. <TopBar /> /common You can see how that is done for in the . /components products page example Why is this structure OK? Adding to the pros of the previous section , since only a few components may require a split. Reusing app specific and shared components is also going to be straightforward. you will have less code to maintain ProductDescription ; {
  ...
} import from "../../components/desktop/ProductDescription" export default ( ) function Products imports only components from . pages/desktop/Products components/desktop Components with Styling Differences Should you create two copies of a component if it contains the same logic, but differs in styling? Looks like it should be shared and placed in the folder, but at the same time its css will need the good old media query approach. /common @ (max-width: ) { ... } @ (pointer: coarse) and (hover: none) { ... } media 768px /* OR */ media That looks ok. Is it the best thing you can do, though? Should you change it everywhere? This is not optimal. What if the logic detecting mobile capabilities changes? Ok, what to do? Ideally the logic for detecting touch devices should be central for the app. Getting a desktop or mobile component to render should be a matter of simply tweaking a prop. Imagine this: -- src
   |-- components
   |   |-- touch
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- desktop
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- common
   |       |-- TopBarLinks.js
   |       |-- TopBarLinks.css
   |-- pages
   |-- App.js is a shared component and may have some visual diffs. In its css this is addressed with a class. <TopBarLinks /> { ... } { ... } .TopBarLinks /* Desktop */ .TopBarLinks .touch /* Mobile */ Then it is used both in and : desktop/TopBar touch/TopBar TopBar = ( <img alt="Logo" src="../../assets/logo.png" />
    <TopBarLinks />
  </div> // desktop/TopBar.js export const => () < = > div className "TopBar" ); and TopBar = ( <img alt="Logo" src="../../assets/logo.png" />
    <TopBarLinks touch />
  </div>
); // touch/TopBar.js export const => () < = > div className "TopBar" That's it. This is how you can render shared components with visual diffs. As a result the css file is cleaner and independent of the device detection logic. Enough said on the possibilities for organizing the codebase. Now, how to glue things together. Load Components on Demand 3️⃣ No matter where the split resides in - application root or individual components, or perhaps both - its implementation is going to be the same. Ultimately the pages from all earlier examples are also components. The task is to load only desktop touch related code in the browser. Loading the whole bundle (all components), but using (rendering) only device specific slices may work, but it's not optimal. A proper implementation requires you to use . OR dynamic import() React docs tell you that relies on that principle underneath and will probably do the job. You could also base your solution on library. For the sake of simplicity and to cover the specific use case of touch/desktop based split, let's further focus on a plain solution. Suspense loadable-components Conditionally Import and Render Components I personally imagine the following in the application root ( ): App.js Import ; { ( <h1>Product page</h1> <Import
        touch={() => import("./touch/Products")}
        desktop={() => import("./desktop/Products")}
      >
        {Product => <Product />}
      </Import> )
} import from "./Import" ( ) function App return < = > div className "App" </ > div See it in the . example Codesandbox app The component (you can name it differently) accepts two props - and . They expect a function returning a dynamic import call. In the example above there are two independent page components that you may want to import/render conditionally. <Import /> desktop touch <Product /> The third prop is a function that does the actual rendering. An obvious benefit of using render prop function here is the opportunity to explicitly pass any props to your component if needed. children {Product => } < = = /> Product title {product.title} description {product.description} Implementation Details What will do internally is to: evaluate which component to load and pass it down as an argument to the render prop function. Import Basic implementation may look like: isMobile = .matchMedia( ).matches; { [Component, setComponent] = useState( );

  useEffect( { importCallback = isMobile ? touch : desktop; importCallback().then( { setComponent(componentDetails);
    });
  }, [desktop, touch]); children(Component ? Component.default : );
} // Detect touch enabled devices based on interaction media features // Not supported in IE11, in which case isMobile will be 'false' const window "(pointer: coarse) and (hover: none)" export ( ) function Import { touch, desktop, children } const null => () // Assign a callback with an import() call const // Executes the 'import()' call that returns a promise with // component details passed as an argument => componentDetails // Set the import data in the local state // The actual component is assigned to the 'default' prop return => () null More on Import and its usage - check . the app context Some notes: - you can use any other mechanism for detecting touch capabilities here. Going a step further, may come from the store instead (if you are using redux, mobx or other global state management mechanism). window.matchMedia("(pointer: coarse) and (hover: none)") isMobile - the actual component is set in and you have to export it using default export ( ). importCallback().then(componentDetails) componentDetails.default export default function Products() Finally, imported data is set to the local state and your component passed down to the children function for rendering. Using requires some prerequisites to allow for proper parsing and dividing the final bundle in parts. You may need to additionally set these up. import() Webpack Config For the split to work there are some file to be made. An example config by can be . If you are using that is done by default. adjustments in the webpack config Dan Abramov found on github Create React App .exports = { : { : ,
  }, : { : , : , : , : }
}; module entry main './src/App.js' output filename "bundle.js" chunkFilename "chunk.[id].js" path './dist' publicPath 'dist/' Babel Plugin If you are using Babel the plugin is required in order to properly parse dynamic imports. @babel/plugin-syntax-dynamic-import Eslint Config is also required to support export/import syntax. Don't forget to update your eslint config file: eslint-plugin-import { : , : [ ]
  ...
} parser "babel-eslint" plugins "import" Again code splitting is supported by default with and you can skip the config steps in that case. Create React App Final Words Check for details on the code split. the full code implementation in Codesandbox I would like to wrap up by sharing my own motivation for having app structure like the one described. It may not be your case, but my observations show a common mindset especially in big corps where a clear separation between product, backend and frontend is in place. In that reality it's much easier (and often the only thing you can do) to overcome process issues with a tech solution, instead of trying to change people. Here is an example: you know that backend will deliver the API in a week, but you also know that you can deliver the UI today. Waiting one week for the backend? The slow backend delivery might be due to organizational issues. The tech solution in that case is to mock the payload and deliver to QA and Product teams early. The same motive plays a role when deciding to avoid the backend by code splitting the app. Frontend-only app split will allow for: as per less backend deps development speed when changes are requested flexibility It also means less headache by not having to confront colleagues and management, and higher confidence as you remain in the javascript land - your comfortable area of expertise. 📩 for my next handcrafted Javascript/React writing. Issued monthly. Subscribe Resources - from React's official docs. Code-Splitting - React - words on code splitting in create-react-app. Code Splitting - Create React App - get an overview on how and when to use React Suspense. Suspense for Data Fetching - configure webpack to support code split in your React app. Webpack Code Splitting - Getting started guide for . Loadable Components - Guide loadable-components - how to better determine device capabilities with media queries. Interaction Media Features and Their Potential Previously published at https://webup.org/blog/react-device-based-code-split/

Glue

How Can Developers Save A Failing Project? - Learn from My Mistakes

Exploring Render Props Vs. React Hooks In 2020

Get a monthly newsletter with my handcrafted Javascript/React articles.

Book a call

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

How to Do a Device-Driven Code Split in React With No Backend

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How Can Developers Save A Failing Project? - Learn from My Mistakes

Breaking the Monolith: A Comprehensive Guide to Code Splitting Techniques

Code Splitting with Parcel Web App Bundler

Effective Code Splitting in React: A Practical Guide

Impress Your Friends With Code Splitting in React

How Can Developers Save A Failing Project? - Learn from My Mistakes

Breaking the Monolith: A Comprehensive Guide to Code Splitting Techniques

Code Splitting with Parcel Web App Bundler

Effective Code Splitting in React: A Practical Guide

Impress Your Friends With Code Splitting in React

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps