Merge pull request #280 from open-formulieren/chore/279-bump-to-rc

Create release candidate

Author: sergei-maertens

.github/CODEOWNERS

@@ -0,0 +1,3 @@
+.storybook/ @sergei-maertens
+src/ @sergei-maertens
+LICENSE.md @joeribekker

CHANGELOG.md

@@ -1,5 +1,29 @@
 # Changes
 
+## 1.0.0-rc.0 (2025-12-23)
+
+First release candidate for the stable 1.0.0 release.
+
+**API changes**
+
+- [`#138`][#138] Internal components now use explicit `isReadOnly` semantics rather than
+  `isDisabled`. This should vastly improve the experience for screen reader users.
+
+**Bugfixes**
+
+- [`#263`][#263] Fixed char count being displayed if no text was entered yet.
+- [`#274`][#274] Fixed the date and datepicker fields triggering validation too soon on blur.
+
+**Project maintenance**
+
+- Updated the documentation (storybook) landing page.
+- Added contributing guidelines.
+- Defined codeowners in Github (initial pass).
+
+[#263]: https://github.comm/open-formulieren/formio-renderer/issues/263
+[#138]: https://github.comm/open-formulieren/formio-renderer/issues/138
+[#274]: https://github.comm/open-formulieren/formio-renderer/issues/274
+
 ## 1.0.0-beta.4 (2025-12-22)
 
 Fifth beta version for the stable 1.0.0 release.
@@ -11,7 +35,6 @@ Fifth beta version for the stable 1.0.0 release.
 - [`#270`][#270] Fixed option descriptions not being displayed in `radio` components.
 - [`#267`][#267] Fixed modals opening scrolling the page to the top.
 
-[#265]: https://github.com/open-formulieren/formio-renderer/issues/265
 [#268]: https://github.com/open-formulieren/formio-renderer/issues/268
 [#270]: https://github.com/open-formulieren/formio-renderer/issues/270
 [#267]: https://github.com/open-formulieren/formio-renderer/issues/267

CODE_OF_CONDUCT.md

@@ -0,0 +1,65 @@
+# Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers
+pledge to make participation in our project and our community a harassment-free experience for
+everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity
+and expression, level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit
+  permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are
+expected to take appropriate and fair corrective action in response to any instances of unacceptable
+behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits,
+code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or
+to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when an individual is
+representing the project or its community in public spaces. Examples of representing a project or
+community include using an official project e-mail address, posting via an official social media
+account, or acting as an appointed representative at an online or offline event. Representation of a
+project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting
+the project team at `helpdesk@maykinmedia.nl`. All complaints will be reviewed and investigated and
+will result in a response that is deemed necessary and appropriate to the circumstances. The project
+team is obligated to maintain confidentiality with regard to the reporter of an incident. Further
+details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face
+temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org

CONTRIBUTING.md

@@ -0,0 +1,60 @@
+# Contribution guidelines
+
+We are grateful for anyone spending their valuable time on contributions to this library.
+
+To avoid dissapointments, before contributing code, please review our
+[Design goals](https://open-formulieren.github.io/formio-renderer/). We cannot commit to maintaining
+features that are not directly beneficial to
+[Open Forms](https://open-forms.readthedocs.io/en/stable/).
+
+However, if you wish to contribute despite these warnings, you can do so in a number of ways!
+
+## Reporting bugs
+
+If you have encountered a bug in this project, please check if an issue already exists in the list
+of existing [issues][issues]. If such an issue does not exist, you can create a [new
+issue][new_issue]. When writing the bug report, try to add a clear example that shows how to
+reproduce said bug.
+
+[issues]: https://github.com/open-formulieren/formio-renderer/issues
+[new_issue]: https://github.com/open-formulieren/formio-renderer/issues/new/choose
+
+## Performing accessibility audits and testing
+
+Accessibility is definitely a blind spot for us - if you can help out with user tests or by
+performing accessibility audits, we will happily receive the results and check what can be done to
+resolve issues!
+
+## Adding new features
+
+We recommend creating a feature request ticket **BEFORE** developing a new feature. This way, we can
+gauge interest in the feature and let you know if we're not (yet) open to it so that you don't spend
+a lot of time on something that will not be merged in the near future.
+
+If you get the go-ahead and start writing code, that's wonderful! We do ask you to keep the quality
+control process in mind - and all of the things below are enforced through Github Actions:
+
+- we use Typescript for its type-safety features - downcasting is frowned upon (i.e. you should
+  really avoid using `as SomeType`!).
+- code formatting is done with prettier, you can run `npm run checkformat` and `npm run format`, or
+  enable format-on-save in your editor.
+- code is linted using eslint, you can run it locally using `npm run lint`.
+- code must have tests - often these will be interaction tests in Storybook, but for unit-test like
+  tests you can write additional tests and run them with vitest.
+- components must be documented in Storybook, so that they undergo visual regression testing.
+- use [NL Design System](https://www.nldesignsystem.nl/) components rather than reinventing the
+  wheel.
+
+In general - check the `scripts` section in `package.json` for the available developer tools!
+
+### Commit messages
+
+Commit messages are very important to us, as they are essential to understand _why_ changes are
+made. They should explain your thought process.
+
+- always refer to the github issue in the commit message summary.
+- stick to commit message best practices by using a short summary, and add additional paragraphs to
+  the body when relevant
+- good things to note down are: alternative solutions considered and reason why they were rejected,
+  the requirements that applied at the time, possible limitations/external factors that were
+  relevant...

README.md

@@ -4,6 +4,8 @@
 [![Storybook](https://img.shields.io/badge/docs-Storybook-FF4785?style=flat)][Storybook]
 [![Coverage](https://codecov.io/github/open-formulieren/formio-renderer/graph/badge.svg?token=446OCQXNUG)](https://codecov.io/github/open-formulieren/formio-renderer)
 ![Code formatting with Prettier](https://img.shields.io/badge/code_style-prettier-ff69b4.svg?style=flat-square)
+[![TypeScript](https://img.shields.io/badge/TypeScript-3178C6?logo=typescript&logoColor=fff)](#)
+[![Vite](https://img.shields.io/badge/Vite-646CFF?logo=vite&logoColor=fff)](#)
 
 The "renderer" is the React render engine used in Open Forms, responsible for displaying the form
 fields for the user to fill out and capturing the input data.

package-lock.json

@@ -1,6 +1,6 @@
 {
   "name": "@open-formulieren/formio-renderer",
-  "version": "1.0.0-beta.4",
+  "version": "1.0.0-rc.0",
   "description": "Alternative Form.io renderer made for Open Forms.",
   "type": "module",
   "exports": {

package.json

@@ -6,9 +6,15 @@ import {Meta} from '@storybook/addon-docs/blocks';
 
 `@open-formulieren/formio-renderer` is a pure React based renderer for Formio form definitions.
 
+[![NPM](https://img.shields.io/npm/v/@open-formulieren/formio-renderer.svg)](https://www.npmjs.com/package/@open-formulieren/formio-renderer)
+[![TypeScript](https://img.shields.io/badge/TypeScript-3178C6?logo=typescript&logoColor=fff)](#)
+[![Vite](https://img.shields.io/badge/Vite-646CFF?logo=vite&logoColor=fff)](#)
+
 ## Quickstart
 
-**NOTE** - this library is still in active development and public API _may_ change.
+As of version 1.0, the public API is stable, and Semantic Versioning applies. The
+[changelog](https://github.com/open-formulieren/formio-renderer/blob/main/CHANGELOG.md) is on
+Github.
 
 **High level API**
 
@@ -121,7 +127,13 @@ Forms.
 
 ## Roadmap
 
-See [Github](https://github.com/open-formulieren/open-forms/issues/5133)
+The port from Formio.js to our own implementation is complete, which was the scope for 1.0.
+
+We now want to realize improvements that were not possible before, in particular:
+
+- improve the `editgrid` component
+- improve the `addressNL` component
+- re-evaluate past deprecations and check if simplifications are possible
 
 ## Design goals
 
@@ -165,9 +177,18 @@ The code base is structured so that:
 - we build on top of `@open-formulieren/types` so that we only worry about the features that Open
   Forms provides/supports.
 
+## Developer mantras
+
+- Your code must be readable for other developers. Double check with them to make sure.
+- Avoid pulling in unnecessary dependencies - check if native HTML features exist. If large
+  dependencies are necessary, see if you can lazy-load them.
+- Similar code is not the same - sometimes repeating/duplicating code is the better approach.
+- Keep final bundle size in mind - use lazy-loading to facilate bundle splitting.
+- Dare to say "no" when something does not fit our design goals or design decisions.
+
 ## Design decisions
 
-Decisions made while ipmlementing the renderer.
+Decisions made while implementing the renderer.
 
 **Backend API interaction**