portfolio-strapi-cms

first run

the client is initially configured to run with the wix strapi remote (deployed) server.

after git clone
in the root run:
yarn

yarn start:client:dev

and you can see the website.

or open codux

run with local strapi server

run node create-env.cjs or provide a port, for example node create-env.cjs 8080 to run strapi on port 8080. It runs on 5000 by default.

this script will create:

• .env file in the strapi package
• .env.development.local file in the client package (.env is pointing to the wix remote server, when you deploy your strapi server change to the appropriate domain )
• generate a rendom project id in the strapi/package.json

yarn start:server:dev to start the local strapi server go the the strapi admin and follow strapi instructions

in a different terminal run
yarn start:client:dev to start the client web app

codux boards with local strapi

if you want to point the App codux board to work with local strapi server you need to change the env variables in codux.config.json to be the same as in your .env.local file.

seed local DB with data

if you want you can copy our content to your local strapi DB. all you need to do is run

yarn workspace @portfolio/strapi run strapi transfer --from https://determined-vitality-9514a6552e.strapiapp.com/admin --from-token b87a8467b27822083506c041a3cd24c32107cea7999bd6a00c6c672268e4b7dd53fc7920d3ffeed9d30d029103230f297890d3ff5948fe13a9fdc9711e12094388f4ae901a4634f2f175c191a6cf7be7c664570afc33345f51dc0765b3e0b517860ab5efdda8737a86fa119c080ae7ed16ef73f8b432474349b90672abe8e0d7 --only content,files

in the root of the project.
there are a few things to pay attention to

• it will work only if you made no changes to the strapi schemas locally
• it will delete all your existing data
• it won't transfer admin users or tokens, so your user should still work.
• you will probably see a warning: warn: (Schema Integrity) Review workflows feature does not exist on destination It's ok. there are no review workflows

scrips

• yarn verify - will run lint and typescript on the project
• yarn build - will build both strapi and client
• yarn test - will run the tests in the client project (there are no tests in strapi)
• yarn start:client:dev - will run the client in dev mode
• start:server:dev - will run strapi in dev mode

** you can run yarn start:client:dev --mode production for the app to use the values in the .env file instead of the .env.development.local file.
see vite docs

this is a monorepo using yarn workspaces. you can run a script in the strapi package with yarn workspace @portfolio/strapi ... or run a script in the client package with yarn workspace @portfolio/client ...

please read the docs on yarn workspaces

stack

• strapi: to store our content and serve it to the client app
• vite: a front end development environment to build our client app
• yarn: to create a monorepo and manage dependencies
• eslint: to avoid mistakes by static analysis of the code
• scss modules: to write scoped css with more ease
• classnames: to easily assign multiple classes to elements
• vitest: to write and run unit tests
• faker: to generate mock content. both for codux boards and unit tests
• SWR: to cache content in the client app, to fetch new content every once in a while (polling).
  And to have a simple api between the content cache and react components.
• react router: to create multiple routes (pages) and navigate between them
• radix-ui navigation menu: to create an accessible site navigation menu. this component comes unstyled
• floatin-ui: to position floating elements, like sub-menus, tooltips, popovers, etc.
• framer motion: to create animations

concepts

why use fake data in boards

most of our codux boards are wrapped in a context provider that returns mock data (using faker) instead of fetching it from Strapi.
we do it for a few reasons

• it allows us to test and design components without adding data in Strapi (or anywhere else).
• we don't need to have Strapi hosted somewhere or running locally to work on the client app.
• it allows us to create boards for different scenarios: very long text, very short text, different numbers of items, etc.
• we can use our boards in tests

using Strapi types in the client app

there are two reasons to use types generated from Strapi schemas in the client app

1. to avoid writing the types by hand
2. to guard against changes in Strapi schemas (typescript will fail if Strapi schema changed)

there are a few ways to achieve this. Unfortunately, there isn't an official one yet.
We chose the way described in this Strapi blog post with some changes.
what happens:

1. Strapi auto generates a contentTypes.d.ts file. which has all the types but not in a way that is usable by the client app
2. we export it in the strapi module see strapi/package.json => "types": "types/generated/contentTypes.d.ts"
3. we added a strapi-types.ts file which imports the strapi module types and uses them to create the correct types for our app (this is code copy-pasted from the blog post + some fixes)
4. we can use the types exported by the strapi-types.d.ts across our client

The main problem with this approach is that it is our responsibility to maintain the code in strapi-types.ts...
Hopefully, one day Strapi will add this feature

boards

most of our components need a context to run in.
one context for the router and another for the data.
for that reason, we have to wrap our components in the boards with context providers

router

because in codux our app runs inside an iframe we have to use a memory router instead of a browser router in the real App
but we can and should use the real routes for page boards. for simple component boards we still should provide a router context, otherwise, if there is a Link in the component it will throw an error. but we don't use real routes, we add a fake route pointing to the component we want to render in the board.

data

we have two options here:

1. to use the same API provider as the App that fetches the data from strapi (local server or remote depending on the env variables in the codux config )
2. to use a fake API provider that generates fake data without actually fetching anything.

board Wrapper components

so we have 3 types of board wrapper components:

1. ComponentWrapper used for simple components. with fake data and fake routes (links won't throw but won't work either)
2. PageWrapper used for page components. with fake data and real routes (links will work)
3. RealDataWrapper used for the App board. with real data and real routes (works only if you have the local strapi server running or the env variables in the codux config point to a remote server).

you can, of course, change/add wrappers as it is convenient for you.