Going from Figma to VSCode

Setting up the project design can take a few iterations, but a good place to start is to make sure all standard components are using the proper design in all states. Once the project is up locally, go to /debug/components to have a good overview over the components and their colors, shapes and layouts. A key thing that has a lot of value to get right early on here is all the button styles and states. Iterate with the designers to make sure this is solid.

Theme variables

A lot of the project and its design will be controlled via the CSS variables available in globals.scss. Update the values here early on to match the Figma design as well. Some of the values should be rather standardized, like spacing and line-heights, but make sure to look into the design in detail so that nothing slips through the cracks.

Blocks and their names

In earlier parts of the process you will most likely have gotten an idea and hopefully also listed what blocks are new for this project, both bespoke project-specific ones and generalized ones, which should by now be part of Forge. These blocks should now be implemented in the project, utilizing the prepared models and blocks from pre-production for data.

When picking names for blocks, try to keep in mind how it will be used and how people will understand the purpose of the block with little other context than the name. It’s also important to make sure blocks aren’t too general. More specific blocks lead to less confusion down the line and easier to maintain code.

For example, if we have a block that is supposed to show two other blocks in a row, next to each other; we could name this block Row, leaving it to be interpreted as a block that supports literally anything.
This comes with a few problems though. One is that it’s hard to know what exactly this Row does. How does it handle spacing? When does the content wrap into a column?
Instead I suggest that we name it something more specific. Let’s say it’s always an image with some sort of text next to it, in the design. Then that is what we need to support, to keep dynamic and complex features to a minimum. A name could be Text and Image Row. This may seem verbose and limiting, but experience shows that it helps a lot with minimizing confusion and dynamic problems further down the line.

You can generate a new block via the hygen command found in package.json:

npm run block [blockName]

Integrations and Extensions

GraphQL Typescript definitions
DatoCMS gives us a GraphQL API that we utilize for fetching data. The queries are in Forge in the folder src/graphql. Queries written here will be used to generate Typescript type definitions.These types are generated via the graphql-codegen script in package.json:

npm run sync-gql-ts

This script will make a call to DatoCMS GraphQL endpoint, look at the schema and generate a generated.ts file with Typescript interfaces and types for all the data. You have some control over how the types are generated, partly via the configuration file graphql.codegen.ts but also via how you write the queries.

You will see that most of the GraphQL queries are composed of Fragments. These fragments will be picked up by the codegen and turned into more granular type interfaces, which are useful in a React context for prop typing etc.

VS Code extensions
Forge has a few recommended extensions to install. You can easily get a list of them by opening the extension tab in VS Code and searching for @recommended.