02: Display static data

With the project in place, open it in VSCode and look around.

Tip

We generally recommend that you install VSCode for SOFA development. It's one of the best IDEs for JavaScript/TypeScript, React & GraphQL and we'll be recommending various VSCode extensions down the road.

You can see a few basic building blocks here:

• The pages directory contains "page components". So far, there's only one: index.js that renders the homepage.
• The pages/api directory contains "API routes" – we'll later use that for GraphQL.

Page components

For your e-shop, you'll create two pages for now:

1. Homepage
2. Cart

🖼 TODO – show the two resulting pages

Replace the code in pages/index.js with this:

// TODO

For the cart page, create a pages/cart.tsx file:

// TODO

You can now run the dev server with yarn dev and navigate between the homepage and /cart. You have created two page components in your app, and by default, Next.js mapped them to two routes, / and /cart.

Let's briefly explore a couple of important concepts at this point:

TypeScript

In the examples above, we used both JavaScript and TypeScript. While teams typically use or the other, technically, it's no problem to mix and match them and in this tutorial, we'll keep doing so – first to show that there's not a big difference in the resulting code, and second to reinforce the idea that you can use whatever style suits you, as is the case with many technical choices around SOFA.

Learn more in this longer topic on TypeScript.

JSX

If it's the first time you see HTML-like syntax inside JavaScript functions, it will probably scare you but don't worry, at this point, this is a proven and well-accepted approach of React.

Learn more about JSX in React docs.

Server-side rendering (SSR)

If you do View Source or use curl to fetch the page(s), you'll see that the server returned full HTML:

<!-- TODO -->

This is an important aspect of SOFA / Next.js – Googlebot and other crawlers don't see any difference from traditional server-side languages like PHP or Ruby.

The main advantage is that the UI is still written in React and JavaScript, and after a few seconds in the user's browser, it will "hydrate" into a fully interactive client-side application, with client-side transitions etc. With Next.js, you get the best of both worlds "for free".

Styling

Let's get to something truly controversial now!

Add this to your index.js:

// add <style jsx> section

And this to your cart.tsx:

// add <style jsx> section

You should now see this:

🖼 TODO

CSS-in-JS

An approach popular in the React ecosystem is to put styles close to component, and in fact make them independent on global styling most of the time. Note how in the examples above, the selectors can simply target h1 and it will only affect that specific H1, not the rest of the app.

There are also some downsides to CSS-in-JS, for example, there is typically a small runtime overhead (depending on the library) or that tooling is typically better for .css / .scss / .less files. However, overall, the "componentization" of CSS is so beneficial that the disadvantages are worth it.

VSCode tooling for styled-jsx

Styled-jsx is a library shipping with Next.js by default and we find it as a good compromise of having the CSS-in-JS benefits while still staying close to the CSS syntax (some libraries diverge quite heavily, e.g., styled-components). So we'll continue using it for this tutorial and suggest it as a good candidate for your real-world SOFA projects.

The VSCode experience is much better with this extension that adds syntax highlighting, code completion and other useful features:

[TODO link & 🖼]

Use whichever styling you prefer!

SOFA doesn't dictate how you do styling, all these approaches are possible:

• Global styling via a few large CSS files (though we'd suggest you look for alternatives)
• CSS Modules – if you prefer editing plain .css / .scss but still want the benefits of scoped styles, CSS Modules are a great middle ground and directly supported by Next.js.
• CSS-in-JS – as above.
• Other approaches like atomic / utility CSS, e.g., Tailwind.

It's really up to you, we just recommend that you use a technique that will not accidentally affect many different components in hard to predict ways.

Target modern browsers

We recommend that you target modern browsers only if you can afford that – it will allow you to use CSS variables and other features that cannot be polyfilled for older browsers.

If you need to support IE11 and older, it's possible (you control every bit of the output) but these docs generally assume modern browsers.

VSCode tips

Before we move on, here are a couple of useful VSCode extensions for you to install:

• TODO
• TODO

You'll also notice how in the dev mode, changes in code are instantly reflected in the browser thanks to Fast Refresh.