JSX as a design tool data structure

Right now importing and exporting from design tools is full of friction. We’re still drawing images and trying port them back to the web.

Design tools are too far departed from their render targets. Not to mention, design tool outputs aren’t a proper source of truth, the production code is. Consider a React web app, we have a powerful, component-based model that uses JSX as a representation of the DOM. Why can’t we use a design tool to visually edit that JSX?

🤔 I think we can.

All roads lead to “the code”

If we accept that “all roads lead to the code”, it seems logical to use the production code as the format for design tooling. Production code has the ability to handle state, it has business logic that transforms input, it even talks to real data. Components are the building blocks and render to the web so design tools can spend less time reinventing wheels for functionality like layout.

To me, the best component model for the web is React and JSX is the best way to write React. It has a rich ecosystem and JSX has the ability to embed metadata that design tools can use and manipulate. You can represent JSX as a tree structure which can be used to manipulate it in a visual editor. This isn’t new, other ecosystems like gaming and even educational tools have had this forever.

We can parse the following JSX:

<header>
  <Logo />
  <nav
    sx={{
      display: 'flex',
      justifyContent: 'space-between'
    }}
  >
    <Link
      to="/the/future"
      sx={{
        variant: 'styles.headerLink'
      }}
    >
      The Future
    </Link>
    <Link
      to="/sunny"
      sx={{
        variant: 'styles.headerLink'
      }}
    >
      Is Bright
    </Link>
  </nav>
</header>

And represent it as:

59301899009__AC93C483-7CA8-4AF4-88B9-4B8C04157FF1

We’d provide a wonderful experience for basic changes in production code for many more members of a team. Web development is visual yet our tools are basic text and CLIs. I don’t understand why this isn’t part of web design/development yet. We’re behind.

Granted, we have tools that are getting close, like Webflow, but I think there are so many potential solutions to this same problem I’d love to see more activity in the space.

Putting my money where my mouth is

I’ve been thinking about this for quite a while now, and believe it’s the time to start prototyping.

There are a couple key elements that make it more of a possibility than before. Firstly, Theme UI’s sx prop, which provides a standard way to inline styles to a component that’s tied to a global theme.

For basic style editing it should be relatively trivial to parse a component render it in one panel, and then expose UI to manipulate the sx prop and other attributes.

An informal specification

For a prototype I plan on supporting a subset of React/JSX based on Theme UI’s sx prop. It’ll be a full-fledge block/page builder that receives JSX as an input and outputs transformed JSX based on the changes made.

It will use Babel to search for, apply, and modify the sx prop and potentially allow for drag and drop modifications amongst different parts of a component. It’ll be tricky to add the drag and drop inline, but at the very least we can provide an ordering panel to make these changes.

Generally speaking, being truly agnostic of all possible data and JSX permutations isn’t a worthwhile short term goal. However, we can focus on a standardized subset for building common components which would fit nicely with Gatsby theme development.

Why does this matter?

Manipulating production code directly in a design tool would be amazing to achieve. It’d allow folks to visually change the header and open up a PR without touching the code itself.

With modern continuous deployment stacks this will allow folks to make changes and see them deployed, in real time, to development/staging environments. This drastically cuts down on deployment overhead, keeps feedback loops quick, and enables more members on the team to contribute.

Eventually this could be combined with communication/commenting software that allows suggestions and requests for changes that can be tracked similarly to a GitHub PR-based workflow.

Most importantly, designers and developers would no longer have a silo and translation barrier between tooling.

Conclusion

I’m pretty bullish on this concept, so it’s time to start iterating a bit and see how an implementation plays out. A while back we experimented with this at Compositor but never really stress tested the idea.




Wanna hack on a solution with me? Drop me an email.