Design with Code – UXPin Merge Tutorial

Are you ready to elevate your design workflow to the next level? In this comprehensive tutorial, we’ll delve into the world of UXPin Merge, empowering you to seamlessly integrate your React app components into the UXPin editor for high-fidelity prototypes.

Gone are the days of static designs. With UXPin Merge, you can dynamically link your React components, ensuring that your prototypes are always in sync with the latest developments in your codebase.

Get ready to unlock the full potential of UXPin Merge – let’s dive in!

Create beautiful layouts without designers

Design production-ready prototypes 8.6x faster. No pixels. pure code.

What is UXPin Merge?

UXPin Merge is a technology for designing with coded UI components that are backed with production-ready code. It’s part of UXPin – a code-based design tool for highly realistic and accurate prototyping. With this tech, you can grab all the specs, JSX code, and any other asset and hand them over for developer to make the entire product development workflow 8.6x faster.

UXPin Merge tutorial – How to use this technology?

UXPin Merge technology works like a drag-and-drop UI builder. You take a component out of the design library in UXPin and put it on the canvas. Then, after you’ve done arranging the layout and setting up components props, you can copy a ready React code (or CSS code for Tailwind library) to your development environment or open it in StackBlitz.

You can build anything you like. From simple dashboards that automate your team operations to more complex, e-commerce stores which front-end is decoupled from the back-end. UXPin has a few templates and patterns to get you started.

We highly recommend you watch a video tutorial of how to use UXPin Merge presented by a real-life web developer, Rachel. She did a wonderful job of walking you through all the panels, functionalities, and features of Merge technology, and she also shows you how to do a design handoff with UXPin Merge.

Watch it on Youtube. Here’s the full playlist of UXPin Merge tutorial.

How to integrate your own components, step by step

UXPin Merge supports Storybook components and React components from open-source libraries, such as MUI, Ant design or Bootstrap.

We want to give more details and show you how easy it is to integrate a React-based library into Merge to design with code on a day-to-day basis. All that without learning how to code!

UXPin Merge allows users to import their existing custom React components in a seamless fashion to create interactive prototypes using real code, which is unlike anything else traditional design tools offer.

This eliminates the need for designers to manually maintain a “second” design system within their design tool and instead provides the entire team with a single source of truth. The result? The disconnect between designers and developers is gone when building digital products. 

We want to save you time so we’ve designed this tutorial to integrate Mozilla’s React Todo App example with Merge. After the integration, you’ll be able to use the app’s components to design an interactive Todo list prototype within UXPin!

Remember to start by requesting access to Merge – you can do it here. After the verification process and the setup, you’ll be ready to design with code! Also, don’t worry about integrating with GitHub – we don’t have any requirement of where the codebase should be located, so you can use whatever you want!

The components

The Todo app has three React components:

1. Form – create a todo item.

2. FilterButton – filter todos by their current state.

3. Todo – a todo list item.

These components are in the `src/components` directory and are outlined in the screenshot below:

When this tutorial is completed, a designer will be able to create a prototype with these components. Your real-world custom design system (DS) likely has many more than three components. However, the concepts we’ll illustrate in this tutorial should apply to your DS as well.

Set up UXPin Merge

To begin, fork then clones the following link https://github.com/mdn/todo-react. Then install our UXPin Merge NodeJS package, which includes our CLI.

  1. Navigate into your project folder cd todo-react
  2. Install UXPin Merge and It’s CLI NodeJS bundle with: yarn add @uxpin/merge-cli–dev
  3. Ignore the UXPin Merge build directory with: echo ‘/.uxpin-merge’ >> .gitignore

A custom design system requires two additional config files:

  1. uxpin.webpack.config.js
  2. uxpin.config.js

UXPin typically doesn’t need to use your entire existing Webpack build process. We’ll use a more minimal and default build for UXPin. Create a uxpin.webpack.config.js file and paste the following code into it:

const path = require("path");
const webpack = require("webpack");
 
module.exports = {
    output: {
      path: path.resolve(__dirname, "build"),
      filename: "bundle.js",
      publicPath: "/"
    },
    resolve: {
      modules: [__dirname, "node_modules"],
      extensions: ["*", ".js", ".jsx"]
    },
    devtool: "source-map",
    module: {
      rules: [
        {
          test: /\.(s*)css$/,
          use: [
            {
              loader: 'style-loader'
            },
            {
              loader: 'css-loader',
              options: {
                importLoaders: 2
              }
            },
          ]
        },
        {
          loader: "babel-loader",
          test: /\.js?$/,
          exclude: /node_modules/,
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react'],
          }
        },
      ]
    }
}

For components you want to use in UXPin Merge, you must specify their file directory in the uxpin.config.js file at the top of the directory of the repo. As you can see in the code snippet below, we’ve only added the ‘Form’ component src/components/Form.js  for now and will add the other components later in the tutorial. 

Create a uxpin.config.js and paste the following content into the file:

module.exports = {
  components: {
    categories: [
      {
        name: 'General',
        include: [
          'src/components/Form.js',
        ]
      }
    ],
    webpackConfig: 'uxpin.webpack.config.js',
  },
  name: 'Learn UXPin Merge - React Todo list tutorial'
};


Lastly, Babel-loader will be used by Webpack to create the app bundle. To install babel use the following commands: yarn add babel-loader –dev then yarn install .

CONGRATULATIONS👏 You’re all good to go and have the minimum configuration required to view the Form component.

Experimental Mode

Using the settings provided in `uxpin.webpack.config.js`, Experimental mode bundles your components and opens a browser window. You can lay out components in a similar fashion as the UXPin Editor. After Experimental Mode loads, drag and drop the Form component from the sidebar onto the project canvas:

We have the Form component but it lacks styling. For that, we’ll create a Global Wrapper Component.

Using a Global Wrapper Component to apply CSS styles

Just like your custom design system, this Todo app contains global styles. These are specified in the `src/index.css` file. All of our components need the styles specified in this file. We can load this file via a Global Wrapper Component. This component will wrap around every component we drag onto the UXPin canvas.

Create a wrapper file:

Copy and paste the following into `UXPinWrapper.js`:

import React from "react";
import '../index.css';

export default function UXPinWrapper({ children }) {
  return children;
}

The `import ‘../index.css’;` line ensures our CSS styles are loaded prior to rendering each component.

We need to tell UXPin to use this wrapper file. Add the following to uxpin.config.js:

wrapper: 'src/wrapper/UXPinWrapper.js',

Experimental mode should open a new browser window with a styled Form component:

Adding the FilterButton with a customizable name

Now we’ll work on adding the FilterButton to UXPin Merge. These buttons are displayed below the Form component:

Adding this component will be similar to the Form component. However, I’d also like to give designers the ability to specify the text that is displayed within the button. We’ll do that via the `prop-types` package.

Component propTypes are mapped to the UXPin properties panel when editing a component. The existing FilterButton component doesn’t use prop-types so let’s add this to `FilterButton.js`:

import React from "react";
+ import PropTypes from 'prop-types';

function FilterButton(props) {
  return (
@@ -15,4 +16,9 @@ function FilterButton(props) {
  );
}

+ FilterButton.propTypes = {
+   name: PropTypes.string
+ }

+FilterButton.defaultProps = {
+  name: 'Button Name'
+};

export default FilterButton;

Two of our three components are now working with UXPin Merge. We have one component remaining: the Todo component.

Adding the Todo component with a wrapper

We’re moving on to our final component: the Todo. These are displayed within the list of todo items in the UI:

When adding the FilterButton, we edited the FilterButton.js file to add propTypes. What if you want to isolate your Merge-specific changes and don’t want to modify the source code of your components? We can create a wrapper that is specific to the Todo component for this. It’s similar in concept to the Global wrapper component we used to apply CSS styles but will be specific to the Todo component.

Type the following:

mkdir -p src/components/merge/todo 

touch src/components/merge/todo/Todo.js

Copy and paste the following code into Todo.js. 

import React from 'react';
import PropTypes from 'prop-types';

// Import the original component
import TodoM from '../../Todo';

function Todo(props) {
  return <TodoM {...props}/>
}

Todo.propTypes = {
  /**
   * If `true`, the todo will be marked as completed.
   */
  completed: PropTypes.bool,

  /**
   * The name of the todo.
   */
   name: PropTypes.string,

  toggleTaskCompleted: PropTypes.func,
}

Todo.defaultProps = {
  name: 'Do Laundry'
};

export default Todo;

We’re importing the original Todo component as `TodoM` and returning this component in our newly defined `Todo` function. We specify propTypes just like we did with the FilterButton component on our newly defined `Todo` wrapper function.

Add ‘src/components/merge/todo/Todo.js’ to uxpin.config.js and restart using ./node_modules/@uxpin/merge-cli/bin/uxpin-merge –disable-tunneling. After Experimental launches a new window, click-and-drag the Todo component onto the canvas:

You’ll see the Todo component along with the default “Do Laundry” todo name. This default name is only applied when using Merge.

Pushing to UXPin

Until you push your design system to UXPin the components are only visible to you. To let your design team use these components we need to push the component bundle to UXPin. Creating and pushing a Merge design library requires two steps:

1. Create the library within the UXPin UI

1. Go to your UXPin account

2. Enter the UXPin Editor

3. Create a new library

4. Select the option import React components

5. Copy the Auth token (don’t share it with anyone and do not place it in any files checked into git repository. This token provides direct access to the library on your account.) The process looks like this:

2. Push the library via the uxpin-merge CLI

Using the token created from the previous stop, run the following from within the project repo:

./node_modules/@uxpin/merge-cli/bin/uxpin-merge push –token YOUR TOKEN 

Your design team can now access the Merge library.

Using the Merge library within UXPin

Now that the Merge design library has been pushed its time to test it out within the UXPin editor:

  • Reload the UXPin Editor in your browser.
  • Select the “Learn UXPin Merge” design system in the bottom left corner of the editor.
  • Click and drag the components from the sidebar to the canvas.

You should have a solid looking prototype:

How does a designer hand off a prototype back to a developer?

Previewing and Exporting

Now that we’ve built a quick prototype in UXPin we’re ready to export it back to our app. We can preview the output and then use Spec mode to copy and paste the JSX code for our components.

Click the play button in the upper right corner of the editor. Once the preview loads click the “Spec” link at the top. You can now click on the components and view the JSX code to generate them in the right panel:

It’s great to push an initial version of our design system. However, you’ll likely need to push out quite a few updates over time.

Pushing an Update

The FilterButton has a “pressed” state to indicate the currently active filter. Looking at the live React app, here’s the difference between the pressed and not-pressed state:

Let’s add support for this state. Make the following change to `src/components/FilterButton.js`:

FilterButton.propTypes = {
-   name: PropTypes.string
+   name: PropTypes.string,
+   isPressed: PropTypes.bool
}

Commit the change to git and push to UXPin:

Merge components are automatically synced to the most recently pushed code. To show the latest, reload the tab showing the UXPin editor. Select a FilterButton. In the right panel of the editor you should see a new “isPressed” property.

Select it to activate this state:

Follow this same flow (git commit + uxpin-push) when you make future changes. Prototypes will automatically use the latest pushed version of components.

Speed up building your product by 8.6x

You’ve taken a React app and pushed its components to UXPin Merge. You’ve also learned how to push updates when you modify components or add new ones. Now your design team can use these components to create high-fidelity prototypes within the UXPin editor.

You can browse the source code for this project on GitHub. To learn more advanced Merge techniques see our Merge docs or reach out to us at hello@uxpin.com.

Don’t have UXPin Merge yet? First, remember to go through the process of requesting access to make the most of designing with code! Try UXPin Merge for free.

MUI 5 Customisation – What is the Best Styling Method?

How to Customize MUI v5 Components

MUI is one of the most popular and robust React component libraries. Developers use MUI to put together user interfaces for React apps. MUI is also useful for prototyping. Using this library, a designer can create high-fidelity prototypes that are fully interactive and ready for usability testing or even the handoff in practically no time.

If you want to try prototyping with MUI, sign up for a free trial. You’ll be able to use the MUI kit for 14 days.

See how close to the real product your prototypes can get when you use a design tool that renders code instead of vector graphics. Explore the full potential of designing with MUI with UXPin Merge. Request access to UXPin Merge.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Why Material UI?

A ton of teams use MUI as a ready-made component library for their design systems. It’s an open-source library, documented and maintained by a large community, so it makes a lot of sense to take advantage of it, instead of wasting resources on building a React library from the ground up.

MUI components are customizable. In this article, we will go through a simple overview of different ways to style MUI v5 components, and why you should consider those styling methods. 

6 Methods of Customizing MUI Components

When discussing the customisation of MUI components, it mostly comes down to how they are styled, with so many in-depth articles on this topic already, we’ll quickly go over the best styling methods.

1. ThemeProvider

The first styling method of MUI would be the ThemeProvider which is a HoC wrapping other components. It injects custom styling, allowing the user to override styles and props.

You’d want to use this to create an easily usable style across most of all of your components, for example, to build a branded library. Since it isn’t a tutorial but a really simple and quick showcase, see a Button component and pay attention to the way you can override styles and start developing a branded component.

2. createStyled

The second way of MUI customization is the styled method. It is a function extended from the styled utility. I found that method very useful when needing to apply styles that aren’t used very often, but they were important enough to spend time on making them reusable.

For instance, if you have a highly used component, but only 25% of the time you need to give it a certain style such as no padding or margin then add a corresponding prop to enable styles in these use cases. Shown in the image below, is a case where you need to remove the padding on a MenuItem component on occasion.

const stylesFromProps = {
 shouldForwardProp: (prop) => prop !== 'disablePadding',
};
const MenuItemM = styled(
 MenuItem,
 stylesFromProps,
)(({ theme, disablePadding = false }) => ({
 ...(disablePadding && {
   padding: 0,
 }),
}));

3. sx={…} Prop

With the newly released MUI 5, the prop sx has been introduced, which is a quick way to define custom styling that has access to theming and it’s variables or any valid CSS you can think of.

This is very useful when you have a component that is being used in multiple places, but you need to have very specific styles or fix a niche issue for a single case, for example, the previously described issue of having to remove the padding on a MenuItem component.

<MenuItem sx={{ p: 0 }}></MenuItem>

4. Component Wrapping

Next, you could try wrapping the component and passing in props to change styles. It’s a possibility, but I found it quite prone to having duplicate props and just generally problematic.

5. Unstyled Components

Another way of customizing MUI components is using the very new and not fully implemented Unstyled Components. It is said to support more components in the coming months.

This seems to be a great solution, as Unstyled Components can be used to create a component library that is not based on Material Design, which is a reason for some not to use MUI. It seems great for avoiding CSS conflicts.

6. MUI Box Component

One option that I’ve only just found out about is using the Box component to override styles. The documentation is continuously being updated, so I’m eager to find out more information about how it works..

In conclusion, these are the recommended methods to customize the MUI v5 components. Those methods provide a lot of possibilities and even allow you to create a unique branded library when using Unstyled Components.

Sync MUI with UXPin Merge

With so many styling methods, you need to give MUI a go. Once you’re ready to create interface design with it, see how UXPin Merge can help you.

It’s a revolutionary solution that allows you to design with full interactivity and functionality of MUI components, and then use those components in the production phase, without the need to translate your design into code with third-party tools. Finally, your design and development teams can share a single source of truth.

Design Handoff: What it Looks Like with UXPin Merge

Developer Designer handoff with Merge

The following article is written by UXPin’s developer, Robert Kirkman, who shares how UXPin Merge makes the design handoff easier from both (a developer and designer) perspectives.

Once the prototypes are ready for production, the designer hands them off to developers. Such a process can be troublesome – the right tool stack being a part of that. There are quite a few design tools that help with design handoff, but what’s the difference between them when handing off prototypes to the developer?

One of the major differences between popular design tools is their approach to the final product of the designer’s work – the prototype of the product. Some of them render prototypes to vector graphics, while others to code. Let’s explore it.

With UXPin Merge, designers can build fully-functioning interactive prototypes with the exact components used in the final product. It syncs fully coded components from a GitHub repository or Storybook to UXPin’s editor. See how UXPin Merge can make you release coherent products. Request access to Merge.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

The Handoff Limitations of Vector-Based Design Tools

Here is a prototype that is going to be handed off from the designers to the developers. Let’s say that it is created in a vector-based design tool. It means that all the components are vector based while the interactions only mimic code.

Recreating UI components

Let’s focus on components first. Some of them might be new, which means that the developer has to build them from scratch. Others are existing components that this engineer may need to modify.

Developing interactions

When getting a prototype built in a vector-based design tool, the interactions might not even exist in the code, so the developer has to create them, or else, call for more designer-developer meetings to understand exactly what is needed and manage expectations.

Preparing design system

This is a system where designers and developers are creating the source of truth for a design system. They are the ones creating the documentation of the reusable master components, and how interactions should work.

Is such design handoff efficient?

design and development collaboration process product communication

This approach works but it might be a bit frustrating, time consuming and tedious. Not everyone will notice that it’s broken or feel an urge to fix it. They don’t have to do that. But, is this the best way to run things?

If you look at it from the perspective of what more can we do to make this better for both designers and developers, I think there is a lot we can discuss. This approach has issues based on where the source of truth is coming from, which is the vector-based documentation and what is handed off to the developers.

What Does Design Handoff Look Like with UXPin Merge?

Prototype created with code components

We’ve taken this perspective of what we can do better during the developer handoff when we were creating UXPin Merge.

No longer are you designing with vector-based components and mimicked code interactions. You’re actually designing with live React components. You can copy and paste the components’ code into your application.

Imagine if the documentation was created by the designer and developer in tandem but the single source of truth for component design and interaction was the actual component code itself. Meaning when the designer is creating prototypes, they are using components that have already been coded, in a live production-like environment with real components.

The components have all the design tokens, interactions and editable properties already defined. Finally, when the prototype is made you can handoff the component code iself.

How Does Handoff with Merge Help Developers?

Imagine how much time is saved when you don’t have to imagine or have meetings with the designer to understand what components they’ve used or what interactions they’ve designed.

The developer handoff is simple, they give you a prototype, you copy and paste the JSX code, which includes the components, component properties and their coded interactions that already exist in the source code.

This is possible because the source of truth is the code itself, the source code.

The only component properties the designer can edit and how they can edit are specified in the source code by the developer, so no unexpected designs are handed your way.

If the designer wants a new interaction added, new properties or changes in the styling of something, they can explain to the developer, then change the source code. There’s no more guessing or wasted time in unnecessary meetings.

How Does It Help Designers?

This sounds great for developers but designers often feel that when they are given components with limited properties to design with, it’s limiting their creativity, right? I don’t believe so, so let me explain.

Imagine playing and designing cool spaceships or castles with your lego back in the day with your friends, or maybe now and alone. No judgement here – lego is cool at any age. You’re all given the same pre-built building blocks, how they connect to each other and how you can use them are already defined and yet each person can create an amazing spaceship, completely different from all the others.

Instead of focusing your creativity on making building blocks and then figuring out how to use them, you’re purely focusing on the latter. Imagine having to create the lego blocks first and figure out how they are meant to work, then build a spaceship.

That’s insane and yet that’s the current accepted state of designing prototypes.

Yeah, I understand designers have to create the components initially with both vector components but developers have a harder time with them. Whereas if you’re using code-based components, both parties only have to create it once, so we’re all happy.

It leaves designers more time to spend on other super cool tasks instead of continuously making adjustment meetings with developers.

Prototype Developer Handoff Using Merge

Handoff with UXPin Merge

For the prototype shown earlier, let’s start with copying the JSX code from the MergeHeader component, created by the designers into our React application, exactly how the developer handoff will work.

As the source of truth is from the source code itself then you can just copy and paste, with a few adjustments such as adding data to objects and the component imports, then you’re ready to view your app in the browser.

Now, all that’s left to do is the same with the rest of the prototype… and VOILÀ! You have a fully working production React app, within minutes, exactly the same as the designer made.

So, in the end, which design process do you think is better?

Improve Design Handoff With UXPin Merge

logo uxpin merge

UXPin Merge can help you improve a lot more than just the handoff process. Visit our Merge page to discover more benefits of designing in code and request access to start the integration process. Go to our documentation to read more about integrating Merge with your organization’s design system components.

UXPin Merge Changelog: Component Documentation URL Tag

MergeThemeSwitcher

Our Merge technology allows you to copy the ready JSX code of your UI code component. However, sometimes it’s hard to find the exact documentation for each component. See how you can do it quickly.

Design with React, Storybook or npm components that your devs build apps with in UXPin’s editor. Create prototypes that can quickly be translated to code and streamline product development process. Discover UXPin Merge.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Our solution to the challenge

Design systems can have very complex, detailed, or hard-to-navigate documentation, so we wanted to reduce your struggles and frustrations of finding it. 

So, we added a very simple but effective feature for doing just that. We’ve added a new JSDocs tag to our component commentating syntax that creates a link in the Merge Preview Spec panel.

Component Documentation

It could be used to link out to usage, prop info, Storybook, or for those without any documentation, it could link to UXPin layout examples. Adding this feature not only saves time but also helps to centralize and integrate all your current processes and toolsets into one place.

How to add it

It couldn’t be easier to implement too, just add a JSDocs comment before your component like the below example:

/**
* @uxpindocurl https://mui.com/api/card-media/
 */
function CardMedia(props) {
return <CardMediaM controls {...props} />;
}

Design with code with Merge technology 

What’s different about a UXPin Merge prototype? You get to use interactive UI blocks that save you from redesigning the same things over and over again. As these blocks are coded components, developers can just copy the code straight from your design.

Using such components not only increases the level of interactivity you wouldn’t be able to reach in an image-based tool but also speeds up the prototyping process.

Designers and engineers have three options for connecting code components with UXPin Merge:

  • Git repository—currently only supports React components
  • Storybook—supports React, Vue, Angular, Ember, and many more
  • npm–bring React components through npm

Read more about Merge.

Sync your Design System components with our design tool and enjoy all the perks! Request access now. 

How to Import Your Components into Storybook and Use Them in UXPin

How to Import Your Components to Storybook and Use Them in UXPin

We’ve recently released our Merge-powered integration with Storybook that allows you to bring Storybook components to UXPin editor and design with them, keeping all the interactions available in Storybook. It helps break down the design and development silos and finally, let product teams use the single source of truth. 

It’s the second integration (we also connect with Git libraries) supported by Merge technology that aims for keeping the parity between design and development, letting designers use the same components as devs do. 

The UXPin-Storybook integration is the first like this on the market, so being a developer and seeing how much it can simplify things, I’ve decided to explore the topic from a developer-first perspective. Read on to learn more about the first step of using Storybook – importing UI code components. I’ve prepared a brief summary of what I experienced when making a project using create-react-app, installing the Storybook package and integrating it into my UXPin account powered by Merge tech for prototyping.

What is Storybook

That’s cool… but like me at the beginning of this journey, you might not have heard of Storybook. Let’s see what it is and what it solves.

So for a TD; LR; If you’ve built projects that include component libraries using Frameworks such as React, Vue or Angular and don’t have a way to view or test each component with any possible state or combination of props quickly, then you can use Storybook to do this. 

It allows you to build interactive component libraries alongside its own documentation internal to the project directory but outside of the main app in an isolated environment. Meaning, it makes your component build process and documentation more efficient and easier to use without changing your original code.

Want a little bit more and a real-life example, sure, here you go. You have a website that’s made up of components, which have several properties and several states. For example, a Form may have states for:

  1. User input
  2. Validation errors and messages
  3. Promotions to be added

To test these states you’d have to props manually and load local versions of the app, it’s just so tedious and I would very rarely test each state when making a change. But, with Storybook, you can test each prop live in a local isolated environment. It makes things so much quicker and easier.

Storybook use cases

Storybook’s main purpose was to allow frontend developers who are working on projects utilizing Javascript frameworks to create and style component libraries. However, like most things, there are additional uses:

  • Project Managers – Improved QA time efficiency without having to load an app to view component changes. Instead just view them on Storybook.
  • Dev ops & Backend developers – No longer do they need to keep the local environment always up-to-date so that other users can see component changes.
  • Designers – Quickly verify the design of UI components and their states are true to your designs.
  • UXPin Merge users – Import your public or private Storybook Library as live React components, where you can make functionally prototypes with no need for programming knowledge.

Importing Storybook

You have to install Storybook in your project. It’s a package, so for my Storybook test I used npx create-react-app to create a React project then installed Storybook using yarn sb init. I chose React because it’s what I’m most comfortable with and the docs seem quite extensive, but in addition, there is support for Angular, Vue, Web Components, Ember and more.

Storybook is now immediately usable after installation, and after it’s complete, simply run yarn storybook to start the local Storybook server, which will open your browser at http://localhost:6006  displaying your local Storybook component library with some pre-installed examples.

My Component

Even though Storybook isn’t plug-and-play as there is a little work to integrate your components, it’s still quite easy and fast. I was a bit confused about the syntax issues but their documentation is great and it didn’t take me long to fix them. Integrating your components is not all or nothing, meaning you can add each component one at a time, which makes the integration easy to troubleshoot.

This is the first component I wanted to integrate – a simple Button which takes several props. 

The next step is to integrate it into Storybook by writing a stories file.

import * as React from 'react'
import PropTypes from 'prop-types';
import ButtonStyles from './ButtonStyles';
 
const MyButton = (props) => (
 <ButtonStyles onClick={props.clicked} {...props}>
   {props.children}
 </ButtonStyles>
);
 
MyButton.propTypes = {
 disabled: PropTypes.bool,
 children: PropTypes.string,
 onClick: PropTypes.func,
 type: PropTypes.oneOf(['primary', 'secondary', 'success', 'error', 'warning']),
 size: PropTypes.oneOf(['xs', 's', 'm', 'l', 'xl', 'xxl', 'xxxl']),
}
 
export default MyButton;

Adding a stories file

First, what is a Storybook story? A story is a possible rendered state that a component can support. You can have multiple stories each to describe a different state, for example, a Button component with stories for a warning, error or submit theme. For more information, look here.

I need to add a stories file for the Button with several args. A stories file contains a ‘story’ describing one or multiple states that your component will be rendered in Storybook by adding args. Each arg is what properties to give to a component when it renders. I can define several args in the same stories file, therefore, I can show all the different variations of each component. For my Button I’ve shown several args, I would need to add more to cover all variants but this is just for example. You don’t have to define the args in the stories file if you’ve defined props in your component file.;

import React from 'react';
import MyButton from '../MyButton';
 
export default {
 component: MyButton,
 title: 'MyButton',
};
 
const Template = (args) => <MyButton {...args} />;
 
export const Primary = Template.bind({});
Primary.args = { children: 'primary', type: 'primary' };
 
export const Warning = Template.bind({});
Warning.args = { children: 'Warning', type: 'warning' };
 
export const XXL = Template.bind({});
XXL.args = { children: 'XXL Primary', size: 'xxl' };
 
export const Stretched = Template.bind({});
Stretched.args = { children: 'Stretched Primary', stretched: 'true' };
 
export const Disabled = Template.bind({});
Disabled.args = { children: 'Disabled Primary', disabled: 'true' };

So put simply, to integrate a component into Storybook requires:

  1. A src/components/[COMPONENT].stories.js which include your component stories in the needed format.
  2. Restart the server if you’ve added a component by running yarn storybook

This is what I meant when saying Storybook is outside of the main app in an isolated environment and doesn’t interfere with your existing code. All added functionality uses the story files, the original code doesn’t change. Additionally, no Storybook-specific libraries are required when creating a stories file.

Automated documentation generation

Another great feature of Storybook is its ability to create your basic documentation automatically based on your source code. This helps tremendously with sticking to a single source of truth and is a huge time saver.

Here are the docs for MyButton component:

It also lists all Args you have in your source code, so you see all the different variants of your components. You can even just copy and paste the code for each!

Publishing Storybook and integrating with UXPin

My experience of importing the components into Storybook hasn’t been too time-consuming – it actually was pretty simple as there is lots of documentation to help. The reason I felt inclined to learn more about this is because UXPin, using our Merge technology has added integrating your local or private Storybook as a library in the app, so I wanted to try it and also document my experience with this too.

So, following the UXPin Storybook integration documentation I got my components integrated into the UXPin editor in a minute. I could then (if I had more components) start to build prototypes using my integrated Storybook component library, in a live code environment, with all component interactions and functionality ready to play with.

screen 3

Summary

Importing components into Storybook is easy and comes with a lot of benefits. On top of that, it can work as a single source of truth for product teams, reducing handoff to a minimum, getting rid of all the design-dev inconsistencies in projects. If you want to try it out, go ahead – our integration is on trial! 

How to Make Design Process Simple for Agencies and White Labeling

How to Make Design Process Simple for Agencies and White Labeling

Anything you can create in code, you can design with UXPin powered by Merge technology. Designing with code components can cut down your time to market and simplify the handoff between designers and devs. It’s all thanks to using the single source of truth and designing with production-ready components. 

Device Viewer
Theme Switcher

We’ve recently featured two really cool React components that you can use with UXPin Merge; the responsive design Device Viewer and Theme Switcher. You might think that UXPin’s technology is only useful for companies with a single design system, but we’ll show you how a large web agency, spanning several smaller portfolio teams, used these two components in an environment built around white labeling.

The troublesome design process in agency

Design agencies can come in all shapes and sizes. Individual small or large agencies or even portfolio companies constantly acquiring smaller teams, each using different technologies. But what does stay the same, are the issues faced when managing branding and creating future-proof, scalable, and efficient design systems.

The software and tools these companies use are incredibly important for solving these issues. Imagine how much time and money is wasted on back-and-forth communication due to using and maintaining multiple design systems and sources of documentation over several technologies and how much more rewarding it would be if you could simplify and improve this.

Agencies using the power of Merge technology

As mentioned in the Theme Switcher and Device Viewer articles, you see what amazing components you can create and how Merge can make complex design ideas easy; all thanks to designing with ready code components. Using your imagination, the possibilities of prototypes you can create seem endless.

Focusing on the Theme Switcher, you can see that it’s just a React component. It shows that anything you can imagine and code can be designed within Merge. It shows how agencies that use Merge can work efficiently with any number of clients, switching between clients’ brands with a click of a button. It’s also an incredibly powerful tool when it comes to requests for proposals (RFPs) and quick-turnaround demos. Imagine if all you had to do to create a new styled prototype to impress potential clients was to edit a simple style file, while your competitors had to create a new prototype from scratch. But, how is this different from using another piece of software and their theming tool?

Theme switching is not specific to UXPin Merge, some design tools have it, but how it’s implemented here is what makes it special, incredibly efficient, and design consistent. 

Unlike other design tools, Merge’s variable values are all predefined in the code and can be done at a component or layout level. Everyone, who uses the components, is designing with the same properties and values, hence everyone has the same tools. Consistency is created from the code itself – a single source of truth, meaning no more errors in branding and future proofs the design system. The library in the editor is also syncing with the Git repo, so there’s no need to remember about updating the components in two separate places. 

Imagine having a design system with a single source of truth. How easy it would be to maintain documentation or have a playground where anyone, be it a designer, developer, or account manager can go and test component props and create prototype presentations. Merge can provide this and it’s only getting better.

As we keep mentioning, anything you can code you can design with. This means you don’t have to install a 3rd party plugin to enable theme switching. Why go through all the complicated steps of adding theme switching to your vector-based design system when you can do everything you need in UXPin powered by Merge technology alone.

Summary

Changing design tools can be a daunting task with lots of worry and problems. There’s currently a very rigid design process that people like to follow and it can be very difficult to step out of that comfort zone and try something new, even if they believe it will be better in the long run. 

But there’s no need to worry as the UXPin team is with you every step of the way helping with any integration questions and issues. 

Want to find out more about Merge technology or would like to try it for yourself?