Getting started

  • Building your first component
  • Managing design tokens
  • Version Control

Building components

  • Styling layers
  • Designing Primitives
  • Interactive components
  • Props
  • Variants
  • Composition

Tips & tricks

  • Stateful components
  • Migrating existing components
  • How do I build this in Visly?
  • Visly + Next.js

Documentation

Version Control

In Visly, all data is stored on your local file system. It's designed to be checked into version control systems like git, so collaborating with your team works the same way it does today when you work with code. You can create a branch, make changes, and open a pull request. This also means none of your component data is stored on Visly servers: you own your code.

What to check in

All your components and design tokens live in the <project-name>.visly file that was created when you created your Visly project; we call this the project file. This file has to be checked in, or else the rest of your team won't be able to make any changes to your component library. Visly also generates code in a ./visly folder (exact location can be configured in-app). This is the folder from which you import components and design tokens when writing code. While it's not required to check this folder into version control, it's best practice to do it, since it ensures developers don't need to remember to run a code generation step after they pull down the latest changes. Also, checking in the generated code makes deployment and testing in CI environments much easier.

Internal files

Along with components and assets, Visly also generates a few other files - you'll notice these when committing code. These are common files used by your components and are not something you need to care about. When updating Visly to a new version, you might see these files change. Just check them in with the rest of your generated components.

Resolving merge conflicts

Something you'll run into sooner or later when working in a larger team is merge conflicts. Visly's command line tool helps you resolve these. If you get a conflict in your project file or any of the generated code, just run visly resolve from the command line while in the same directory as your project file. This should resolve all conflicts and generate new code files based on the merged project file. If you don't have the visly command line tool installed, you can install it in the app.

In addition to the resolve command, the command line tool also offers an install command. This can be useful for generating new code based on your project file without opening the Visly app, for example when generating code in a CI environment.