Omgevingsbeleid front-end ·

Objectives

The Province of South-Holland believes that everyone should be able to easily view its policies. By digitalizing them, the province aims to make its policies more transparant, accesible, current, and informative. This way new initiatives can be carried out faster and better and in turn will result in more coherent policies. By storing policies in a database instead of in a document, the province also aims to make the proces of creating new or adjusting policies more efficient and in line with the new Dutch standards (STOP) for publishing governmental plans.

Application

The application digitalizes the 'physical living environment' policies of the Province of South-Holland. Non authorized users can search policies by text or using a map, see in what area they apply and and view connections between policies. Authorized users can adjust and manage the policies. You can view the roadmap here.

Pre-Requisites

Setting up a local version

Clone and install packages

Create a new folder within your documents where you’ll clone the repository to. In Github go to the tab ‘Code’. Click the green button ‘Clone or download’ and copy the link. Using a Terminal, navigate to your recently added folder and run:

$ git clone https://github.com/Provincie-Zuid-Holland/Omgevingsbeleid-Frontend.git
$ cd Omgevingsbeleid-Frontend
$ yarn

Create a .env file

Create a .env file in the root of the project.

VITE_API_URL_DEV = ''
VITE_API_URL_TEST = ''
VITE_API_URL_ACC = ''
VITE_API_URL_PROD = ''
VITE_GEOSERVER_API_URL = '' // Used in the Geoserver API url (in axiosGeoJSON.ts)
VITE_API_ENV = 'dev' // Used to get correct API url (in instance.ts)
VITE_KEY_API_ACCESS_TOKEN = '' // Used to set login token
VITE_KEY_IDENTIFIER = '' // Used to set login identifier
VITE_ENABLE_AXE = true // Used to see accessibility issues in the console

Available scripts

This runs the app in the development mode. Open http://localhost:3000 to view it in the browser. The page will reload using Vite HMR if you make edits to the code. You will also see any lint errors or accessibility improvements in the console.

yarn start

Launches the test runner in the interactive watch mode. See the section about running tests for more information.

yarn test

Builds the app for production to the **\*build**** folder. It correctly bundles React in production mode and optimizes the build for the best performance.

yarn build

Source File Structure

The project uses the following structure:

src
- api
- App
- components
- config
- constants
- context
- css
- fonts
- hooks
- images
- mocks
- pages
- store
- templates
- types
- utils
- validation

src/api

The api folder holds our API Functionality. We use Axios as the HTTP client in combination with React-query. In the /api folder there are three files for the different API's. It contains:

instance.ts - Which is our general API (check API docs for more information about the different endpoints)
axiosGeoJSON.ts - Which is our API to connect to the GEO Server
axiosLocatieserver.ts - Which is our API to connect to PDOK Location server

There are also two generated files which holds all of the endpoints and models. These files are generated using Orval:

fetchers.ts - Contains all API endpoints
fetchers.schemas.ts - Contains all Typescript models

These files can be generated using the following command:

yarn generate-types

src/App

Contains the main application component, which contains the sub components and the routing.

src/pages and src/components

The folder /src contains two main folders for our components. It contains /pages and /components. The /pages folder contains the main files for specific pages. The /components folder contains the universal components. When a component is page specific we place it in the specific /pages/page folder, to not further clutter the /components folder.

Every component sits in its own folder with the name of the component. In the folder there are at least two files:

index.ts - importing the ComponentName.tsx and exporting it
ComponentName.tsx - Containing the component code

The reason for this approach is so that we can organize our code (and if needed it’s tests) in folders, import from the folder name and not end up with multiple index.ts filenames in our code editor.

src/constants

This folder contains the constants for our dimensions and

src/css

For our styling we use Tailwind combined with Sass. The CSS folder contains our styles.scss, tailwind.css and tailwind.src.css files. In our tailwind.src.css we define our custom classes which we apply tailwind classes on.

Every component is styled with Tailwind classes, much like Styled Components, but only then with utilities classes.

For when we need to apply specific styling to an element (e.g. calculating a specific width/height for an element) we create a custom class that we style in our styles.scss Sass file.

src/utils

Contains functions that are used in different components.

src/hooks

Contains hooks that are used in different components.

src/images

Contains the images that we use in the front-end, like the Provincie Zuid-Holland logo.

src/config

Contains the configuration files for all possible policy objects.

Testing

Static testing is done via ES Lint. Unit testing is done with Vitest and React Testing Library.

Contributors ✨

Thanks goes to these wonderful people (emoji key):

_Coen 🎨 🖋 📓 ️️️️♿️	_{Aiden Buis} 💻 ️️️️♿️ ⚠️ 📖	_{Stef Winterswijk} 💻 ️️️️♿️ ⚠️ 📖	_Paulien-Wan ⚠️	_JasonKAEC 💻 ️️️️♿️ ⚠️ 📖
_HagenaarC 💼	_{Eric Herman} 🧑‍🏫	_{Bernard Vuijk} 📆	_Erik 🚧 🖋 📓	_{Swen Mulderij} 💻
_Kingmar1 💻	_ReadMarten 💼

This project follows the all-contributors specification. Contributions of any kind welcome!