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.
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.
It is the intent of the Omgevingsbeleid development community to develop the codebase collaboratively. Adhering to the criteria set forth in the Standard for Public Code gives us confidence in the process. Therefore, The Province of South-Holland is committed to maintaining and developing Omgevingsbeleid front-end at a level of quality that meets the Standard for Public Code.
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 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
VITE_GTAG_ID = '' // Used to enable tracking using Google Tag Manager
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
The project uses the following structure:
- src
- api
- App
- components
- config
- constants
- context
- css
- fonts
- hooks
- images
- mocks
- pages
- store
- templates
- types
- utils
- validation
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 ServeraxiosLocatieserver.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 endpointsfetchers.schemas.ts
- Contains all Typescript models
These files can be generated using the following command:
yarn generate-types
Contains the main application component, which contains the sub components and the routing.
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.
This folder contains the constants for our dimensions and
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.
Contains functions that are used in different components.
Contains hooks that are used in different components.
Contains the images that we use in the front-end, like the Provincie Zuid-Holland logo.
Contains the configuration files for all possible policy objects.
Static testing is done via ES Lint. Unit testing is done with Vitest and React Testing Library.
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!