Closed crates closed 2 years ago
@raymond-lam - Any chance we could get someone to triage this issue? It's pretty critical that we get a resolution in order to use this tool.
@crates Sorry about the delay. I just put out a PR to fix this.
@crates The fix should be in v2.9.1
@raymond-lam - Thanks VERY much for this fix! It's definitely closer to where it needs to be now, but we're still getting a similar error when trying to add a new form element or section to a form that has dependencies.
So now, we can load the forms that previously crashed on load, but when adding a new item to those, we get:
Cannot read properties of undefined (reading 'startsWith')
The error originates from: addElem > addElem > addCardObj > getIdFromElementsBlock
Please let me know if there's anything that can be done to resolve this, or if I should open a new ticket. Thanks again!
BTW, this happens when using a form that has nested dependencies like the example I posted above. It only occurs after clicking the green/white plus sign button, then selecting either new form element or form section (either will produce the bug), and then clicking the blue "Create" button.
One thing you might consider is to use null propagation operators whenever inspecting properties. (It's more commonly known as an optional chaining operator. Not sure where I picked up the other name.) Doing this will help mitigate a lot of cases where you might otherwise encounter bugs.
For instance, I'm noticing errors around the getIdFromElementsBlock method in formBuilder/utils.js:
...names.map((name) => {
if (name.startsWith(DEFAULT_INPUT_NAME)) {
const index = name.substring(defaultNameLength, name.length);
You might consider adding question marks before your periods to help with undefined errors:
...names.map((name) => {
if (name?.startsWith(DEFAULT_INPUT_NAME)) {
const index = name?.substring(defaultNameLength, name.length);
Or, alternatively, specifying a default value:
...names.map((name) => {
const safeName = name || '';
if (safeName.startsWith(DEFAULT_INPUT_NAME)) {
const index = safeName.substring(defaultNameLength, safeName.length);
I don't know the library enough to open a pull request, but wanted to suggest those possibilities. Thanks again for all of your excellent work on this library! It's greatly appreciated. =)
@raymond-lam - Sorry to keep bugging you. Any chance of this getting a fix soon?
@raymond-lam - Sorry to keep bugging you. Any chance of this getting a fix soon?
I can't promise a timeline but I am looking at this.
I haven't forgotten about this....
Glad to hear it! We're showcasing a demo of a solution that uses your form builder this week, but without the bug fix we can't edit previously-built forms that have dependency fields (which for our use case, is all of them). We were wondering if we'd have to rewrite the form portion of our app entirely as a result... But for now we're still holding out for a possible fix.
I can’t guarantee that I’ll have a fix for this by the end of the week. You should assume that I won’t, to be safe.
@crates I think I found the fix. I'm issuing a PR -- hopefully I'll release a new version in the next day or so.
You're my hero, homie. Your timing is absolutely impeccable. Thanks a million!
@crates hopefully v2.9.2 fixes this bug!
@raymond-lam - Not every FOSS project maintainer I've seen has been on top of things, but you and your team are 100% amazing with these updates. Thanks a million. Everything is working phenomenally. You are a hero!
This is a bug with the Gingko Bioworks form builder, which has already been addressed in the RJSF core code base.
If you have fields where some answers or form keys are dependent on other ones, the order in which the JSON is parsed must be maintained in order for the form data to be read in correctly. However, this is a problem: JSON's data specification is such that the order of the keys shouldn't be relevant in how the data structure is processed.
In other words, if you stringify the JSON, and then parse that string, the keys become alphabetized by default. Reordering JSON keys shouldn't break the way that JSON is processed... however, in your implementation of RJSF, this is exactly what happens. As a result, when instrumenting your form builder in any scenario involving
JSON.parse()
, an error is introduced.Thankfully, there is already some code available in the RJSF core code base that could likely be appropriated to resolve the same problem in the Ginkgo Bioworks form builder. Let's start with some bug reproduction data.
Here's the data schema you may use to reproduce this error:
Here's a UI schema to go with that:
If you paste those into the Ginkgo Bioworks form builder demo, you will notice two things right away.
First, the form builder crashes with the following error:
TypeError: Cannot read properties of undefined (reading 'dependents')
Second, when previewing the form (which uses RJSF core, and therefore this bug isn't an issue), you will notice that the "Preview Form" tab is rendering the above form just fine.
You can also try pasting the same code into the RJSF Playground, where it works just fine.
When this schema was originally built, the data was entirely the same as it is now. However, the keys arrived in a different order, which allowed the form builder to process this data just fine. Now that the order of the keys has been changed, we are getting this bug introduced because a field is being loaded with dependencies in its "oneOf" implementation, which haven't yet been loaded into memory.
Thankfully, a solution shouldn't be too far away. Have a look at the code starting on line 810 of the utils.js file from RJSF core:
It looks like this code may have been designed to solve exactly this bug. We're hoping you can take a look, and potentially incorporate the same code into the Ginkgo Bioworks form builder. Solving this bug is an important ingredient to ensuring that dependencies work even after the keys in any JSON object are reordered.
Let me know if you have any questions, and thanks very much for your diligent efforts on such a valuable tool!