`patternProperties` number keys make the input get rendered at the very top of the `Form`

[TheOneTheOnlyJJ]

Prerequisites

• I have searched the existing issues
• I understand that providing a SSCCE example is tremendously useful to the maintainers.
• I have read the documentation
• Ideally, I'm providing a sample JSFiddle, Codesandbox.io or preferably a shared playground link demonstrating the issue.

What theme are you using?

core

Version

6.0.0-beta.8

Current Behavior

Adding a new patternProperties key that is a number makes the key name input get rendered at the very top of the Form:

Notice that keys that have non-numeric characters in them are not affected by this issue.

Expected Behavior

Keys should at least remain grouped.
It would be intuitive to always have them rendered in the order they were added.

If they should be reordered dynamically amongst themselves, I don't know.
Maybe this could be a customizable behaviour set through a new prop or UiSchema property? Just like lists allow reordering, maybe?

Steps To Reproduce

1. Go to the playground patternProperties example.
2. Change the regex of the JSON Schema patternproperties property to "(.*?)", so it matches anything.
3. Add a new property with a purely numeric key.
4. Observe where the field gets rendered.

Environment

Irrelevant

Anything else?

No response

[heath-freenome]

@GlassOfWhiskey I love that you added the new feature and now people are using it. I was wondering if you could look at this issue and hopefully provide a fix?

[GlassOfWhiskey]

@heath-freenome can you give me permissions to open branches directly in this repository, so that I can manage issues more raplidly?

[heath-freenome]

@GlassOfWhiskey Unless I'm creating a release, I usually just push fixes from my fork and make the PR here. It takes me the same amount of time generally after I sync my fork with the main line

[GlassOfWhiskey]

This behavior derives from the formData object, which is a standard JavaScript object that does not preserve the original insertion order. Using a Map instead of a simple object could solve the issue, but it is not clear to me how to enforce this behavior in the ObjectField class, as when the render method receives the formData object it is already too late.

On the other hand, defining an explicit order through the uiSchema seems to be already supported through the ui:order property, which overwrites the original JavaScript property order:

react-jsonschema-form/packages/core/src/components/fields/ObjectField.tsx

Lines 268 to 269 in b5b9551

	const properties = Object.keys(schemaProperties);
	orderedProperties = orderProperties(properties, uiOptions.order);

[GlassOfWhiskey]

@nickgros @heath-freenome any further comment on this one?

[nickgros]

Changing formData objects to maps could be a risky/complex change. Maybe in the ObjectField we could introduce some state that preserves order for additional property elements only?

[heath-freenome]

@GlassOfWhiskey Looking into the ObjectField code, we are using the orderProperties() function in @rjsf/utils to do the ordering. Maybe we can update that to pass in an additional object that indicates which are additionalProperties and always make sure they go last unless they are explicitly mentioned in the order array? Then when we call it in ObjectField, we can pass in the additionalProperties state value as that object. Did you want to take a swing at this?