Feature Request: static types when editing

[yoiang]

Hello! I'm unclear if this relates to #124, I had trouble understanding the ask there so I apologize if this is a duplicate!

When editing a field with a primitive type, regardless of the type onEdit passes a result whose new_value is a string, rather than maintaining the previous type. It would be great if editing maintained the original type!

Edit: My mistake, I just noticed the two sets of controls. Is there a way to only show the type safe set?

[mac-s-g]

when editing a value, RJV attempts to parse and detect primitives. When it does, you'll get an additional submit button indicating the detection.

If you submit with ctrl+enter and there's a detected primitive, the primitive will be submitted by default.

I hope this answers your question. If not, don't hesitate to re-open this issue.

[yoiang]

I apologize, I should have been clearer! It’d be great to have a component prop option to only allow type valid values from edits. On Wed, Jan 24, 2018 at 3:14 PM Mac Gainor notifications@github.com wrote:

Closed #163 https://github.com/mac-s-g/react-json-view/issues/163.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mac-s-g/react-json-view/issues/163#event-1440313382, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFedl3qEIlisrJ7C-ocFJu-dC3E68R3ks5tN48tgaJpZM4RqQTd .

[mac-s-g]

would string be a valid type? that's the default type for all inputs currently.

or does the user define what types are valid?

[mac-s-g]

oh, maybe you're thinking there could be a prop (say editType) that dictates the input type for onEdit.
so if editType = "integer", then you would see a number input and only numbers would be valid inputs.

is that what you're thinking?

[yoiang]

I was thinking for pre-populated JSON where a member has a value of a certain type already specified having an prop that makes sure a user can only update that member with a value of the same type that it already is.

{
  "iAmANumber": 1234,
  "i_am_a_string": "asdf" 
}

In this example with this prop enabled editing iAmANumber would only show the UI for accepting a valid number type where i_am_a_string would only show the UI for accepting a valid string type. The type safe acceptance UI are already available to react-json-view, it would be a matter of hiding the UI that stores the value as a string.

It's unclear what this means for null values, however, and would require something extra for array types, either some smarts on the component's part or something similar to JSON schema. But for the usage I have in mind even not allowing altering null or array types (or adding new members to an object) would be a gem. It would essentially make react-json-view into a very easy to use and quick to implement data form.

[mac-s-g]

thanks for all the detail! this request makes more sense to me now. I think the request should be combined or at least associated with #115 . that is, a JSON Schema would specify the allowed type of a value. the edit controls would reflect the allowed type when a user edits a value.

[yoiang]

Would you be open to a PR with just this prop, one that hid the UI to save a value as a string and only showed the type safe UI when editing?

[mac-s-g]

yes, but how will you know the type without a json schema?

[yoiang]

I'm assuming that the component's one set of controls currently determine the type of a member based on the value of that member.

When a JSON Schema isn't present the prop would:

• only allow editing values that already have a value (and thus their type can be determined) OR
• will also allow assigning null with a value and then that value becomes the determining type. This second one seems more complicated, there'd have to be a way to specify string vs anything else.

[mac-s-g]

so with option 1, if you edit an integer value, you would only be able to input an integer. is that right?

[yoiang]

Exactly, the UI, as it currently does for the type safe input, would only let you save a valid number. Integer vs float I feel less strongly about since they aren't basic Javascript types On Wed, Jan 31, 2018 at 7:59 PM Mac Gainor notifications@github.com wrote:

so with option 1, if you edit an integer value, you would only be able to input an integer. is that right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mac-s-g/react-json-view/issues/163#issuecomment-362123129, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFedhW4kldHlp_VpYragroX77Uzu7kfks5tQQyKgaJpZM4RqQTd .

[mac-s-g]

yea that makes sense. maybe call the prop staticTypes or something? I'd be okay with adding a feature like that. If you're comfortable posting a PR, I can definitely review. I can also take it on, but I might not be able to get to it for a while.

I'm gonna re-open this issue as a staticTypes feature request.

[yoiang]

I have some free time coming up, I'll take a stab at it 😊

Static types as in the prop ensures that the type of the member does not change?

[mac-s-g]

Cool. Yea, that's what I was thinking.

On Feb 1, 2018 5:13 PM, "Ian G" notifications@github.com wrote:

I have some free time coming up, I'll take a stab at it 😊

Static types as in the prop ensures that the type of the member does not change?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mac-s-g/react-json-view/issues/163#issuecomment-362454780, or mute the thread https://github.com/notifications/unsubscribe-auth/AD6FXiXur9TC1rB_5yffb2OVt_qieWQ4ks5tQmEbgaJpZM4RqQTd .

[yoiang]

🤘

[mrbfrank]

@yoiang @mac-s-g Hi I have a similar use case wishing to lock data types, did we come to any conclusion here with impementing staticTypes or JSON Schema?

I do think JSON Schema makes the most sense, for instance if you have a null value.. you'd need some way to enforce a type when adding a value.

[yogiindia]

Its great user is provided with 2 submit options. But if a developer wants to force validation, then, in that case, single submit option must be there. There must be an option to turn off 2 submit option and instead provide only one.