Super excited to open source this — I'm trying my best to bring design & engineering closer together at Airbnb (and in the world), this has been a super useful project.
I'll be hanging out in this thread all day if you have any questions / want to flame me :)
[tl;dr] - This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.
Static documentation is a lie waiting to happen. Once docs are even slightly out of date, people lose trust and eventually abandon them.
On the engineering side of the dev/design process, this is easy to work around. We generate documentation from code and structured comments, which allows us to trust our docs as an up-to-date point of truth.
If you're building a design system that both engineers and designers will work with, there's no real solution to keeping sketch symbols and React components in sync. You're essentially stuck maintaining "static documentation" for designers in the form of a sketch file.
More often than not, things get busy, or someone forgets to commit a change to the sketch file, and the sketch symbols fall behind the code used in production.
Developers start to receive mocks that don't match the "standard" components they're using. Designers start to wonder why fidelity is lost by the time features make it to production. The design system falls apart.
`sketch-reactapp` will help us deal with the static documentation problem the same way we deal with it on the engineering side of things: generate from source.
This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.
Congratulations on the launch!
1.) Design your thing in Sketch
2.) Code your thing in a text editor
3.) Port your code over to this new tool to see it rendered in Sketch?
Like I said. There's some value there (accounting for the changes between 1 & 2), but the workflow feels weird. Maybe someone from AirBnB design can jump in and enlighten me.
As with most misunderstandings/disagreements/arguments in the programming world, this confusion arises from people in different contexts using a tool for one purpose, but not realizing that other people are in different situations trying to achieve different goals with those same tools.
(Specifically, if you are an agency or freelance designer/developer, and you are building a bunch of different sites, then this tool does not serve any useful purpose... but if you have an underlying "design system" and a large company with lots of different products all sharing the same basic design, and a large team to go with it,then this starts to make a lot more sense.)
I do think that design systems can be helpful for smaller, or even 1 person teams as well. It helps you to apply meaningful constrains for your design and reuse common components across the product to shorten development times.
With the library we have both designers and developers can construct completely new views or modifications fairly fast. https://twitter.com/karrisaarinen/status/849733176150773761
Where the React-Sketchapp comes in is help us to keep the system up to date for designers, and in the future build other tools that can help the design workflow.
Where are your API docs coming from? When you say "the same source", is this because your frontend/backend code is sitting together in a mono-repo?
Not familiar with the AirBnB architecture so I'm interested to know how API docs are adjacent to this topic.
I would think programs like Sketch are useful in general because they give designers a nice way to design things without adding the extra layers of abstraction that code brings (i.e. they can just draw things with a mouse instead of writing instructions that tell the computer how to draw things). But if Sketch is just another rendering layer of react components, then what is the point of having it... why not just look at the rendering in a web browser?
Or am I misunderstanding and there's a way for react code to be generated from Sketch? (Despite this statement in your blog post: "As the industry has coalesced around Sketch, people have sought to generate code from Sketch. This is exciting, but for our challenges we wanted to do the exact opposite — to keep DLS in sync we have to generate Sketch files from code.")
also it opens up things like "using real (suboptimal) data" or cross-project-wide refactoring of design, etc
So there would be one sketch file for the basic components that is generated from the React code, but the designers who design specific pages of the site (for example) would still design in sketch, but pull from the components of the one "read-only" (react-generated) sketch files. Very cool!
We have a design systems team that creates & maintains the system (in collaboration with our product designers), resulting in read-only Sketch templates. when _designing with_ canonical components our product designers are using that template, so it's kind of the same workflow - we're just creating the read-only templates from code rather than by hand.
If so, does is not lengthen and complicate a lot your design process?
> the designers who design specific pages of the site (for example) would still design in sketch, but pull from the components of the one "read-only" (react-generated) sketch file
Maybe under a "why use this?" heading?
This is a good question — I’m a technical-leaning designer so I’m partial to just using browser-based tools. I think things like Deco and Expo Snack are wonderful.
That said, I’m specifically looking at improving the efficiency of designers’ workflows without changing them. My team is part of DesignOps at Airbnb, maybe useful to consider it analogously to DevOps. ~= “We’re changing the servers that our applications are deployed on without forcing our engineers to learn a new language”.
Anyway, 1) having Sketch templates always-in-sync with real components is huge, 2) we’re building custom UIs on top of Sketch to use those components (which we may open source eventually), 3) this is a baby step to get us to the point where component-centric tools like Deco and Subform are good enough to realistically switch our design team to.
In theory a full design system has most individual pieces defined. You know what your button styles, inputs, headers, etc are and designing new layouts is often a matter of rearranging these various components — you'll occasionally need to design new ones, so that's the outlier here.
This ensures designers are using a single source of truth when it comes to existing components (which is pretty spectacular, because traditionally designers often maintain an overlapping library of static components for design purposes). It also helps hugely that I could pull in real data instead of trying to transpose some real-ish information into a static mock-up.
And of course there's still that design/developer grey area. I'm educated as a designer, but I'm extensively knowledgable about HTML/CSS/SASS — and that still only takes me so far. I know basic JS, but I'm not going to pretend that I can use React. Sometimes I still need to build static mock-ups so I can try out animations or storyboard userflows, do usertesting, etc.
It has a Sketch plugin that does a rather competent job of converting Sketch layers/groups into components. (For example, you can prefix a Sketch group with "c:", and React Studio will interpret it as a component.)
Here is a live video demonstrating the Sketch -> React Studio -> React code workflow: https://www.youtube.com/watch?v=Rfd7zmlFZw8 (It's in realtime with detailed explanations, so it runs about 40 minutes.)
Disclaimer: I wrote a pile of code for React Studio.
Ideally, with a perpetual license with 1-year of free upgrades.
I think it would be super cool if React Studio could automatically create a GraphQL api based on the structure of the component data.
We are already doing small experiments in this direction at Graphcool (for example graphql-up https://www.graph.cool/graphql-up/)
Do you think anyone at Reract Studio would be interested in talking more about this? They can ping me at soren@graph.cool :-)
https://themeforest.net/item/material-design-reactjs-admin-w...
or
A lot of people when they first learn about this project have a hard time understanding how it would be useful - so you're not alone!
I tweeted ([0]) about this briefly and thought I'd copy here for the benefit of readers in this thread:
> the wild thing about react-sketchapp is that we can now bootstrap designs with the actual code that powers the product we are designing
> it took me a little while to realize the paradigm shift. we normally think of the code / implementation as the end of the process
> this allows us to use production code not only for our production clients, but also for starting the next iteration
> react being decoupled from the underlying UI implementation unlocks a lot of possibilities. this is just one.
> we are starting to view our react components for our design language as not just an implementation, but as the specification itself
[0]: https://twitter.com/intelligibabble/status/856941689029640192This is exactly what I'm doing with Semantic UI React. I'm prototyping in React, and building my own visual language on top of the visual language of Semantic UI. I see how I could instead render my components to Sketch instead (if a really great Sketch file with all the Semantic UI components existed).
Thanks!!!
- René etc is more conceptual - it’s obviously not a practical day-to-day tool
- React Sketch.app solves the problems in our org that I can do something about, but also lets you do combinatorial/permutational exploration (see the GIFs in the intro!) because _it’s just javascript_.
Both embrace the paradigm of UI-as-a-function-of-data, and really are indebted to the mark that Guillermo left on my brain with https://rauchg.com/2015/pure-ui
It also led to some exciting new uses:
- component pickers / editors for Sketch that are backed by real components rather than Sketch symbols (build your own UI)
- automatic accessibility checking / internationalization
- using real data in Sketch with real GraphQL queries etc
- as a building block for using Sketch as a canvas for the design tools of your dreams, whilst maintaining compatibility with the tooling your designers use today
Can you elaborate on the automatic accessibility checking? Are you testing the sketch file or the react-primitive code for accessibility tags?
AirBnB recently released Lottie that requires After Effects but when compared to Principle, AE feels like Photoshop compared to Sketch. I have a feeling that not many UX designers on Mac want to go back to Adobe tools. Certainly, I don't want to touch Adobe tools again.