Show HN: Generate React forms from JSON form schemas(github.com)
github.com
Show HN: Generate React forms from JSON form schemas
https://github.com/SteveVitali/react-form-generator
27 comments
I have some experience in this. Problem is, JSON Schema doesn't give you some attributes like order of properties for building the form.
What makes sense is extending JSON Schema with optional properties that fill in things JSON Schema doesn't provide yet make it work with nothing but a JSON Schema.
json-editor[1] does a very good job in this regard.
Libraries like these are repeating what people have done already previously (classic JS framework DRY problem). They will need to solve a lot of corner cases to mature. Recursion, oneOf and some other JSON Schema properties are pretty hard to implement.
[1] https://github.com/jdorn/json-editor
What makes sense is extending JSON Schema with optional properties that fill in things JSON Schema doesn't provide yet make it work with nothing but a JSON Schema.
json-editor[1] does a very good job in this regard.
Libraries like these are repeating what people have done already previously (classic JS framework DRY problem). They will need to solve a lot of corner cases to mature. Recursion, oneOf and some other JSON Schema properties are pretty hard to implement.
[1] https://github.com/jdorn/json-editor
It's pretty easy to extend JSON Schema with all sorts of other metadata about how a UI should represent the data, or how automated tools should interact with records, making your JSON Schema the single source of truth for your entire data model. The cool thing is that you can actualy write a JSON Schema that extends http://json-schema.org/schema which is the JSON Schema that describes JSON Schema, so you can validate that your use of your custom extensions to JSON Schema aren't misspelled or inconsistent. And that meta-schema can also be validated by http://json-schema.org/schema... It's schemas all the way down!
Getting back to the point, my company is using this exact approach in production, with Python and client-side Javascript consuming the same schema. We have a React component that essentially does what https://github.com/jdorn/json-editor does, but customized for our organization. JSON Schemas make it so easy to add entirely new attributes to our data models and have them consistently validated across the board. Can't imagine doing it any other way.
Getting back to the point, my company is using this exact approach in production, with Python and client-side Javascript consuming the same schema. We have a React component that essentially does what https://github.com/jdorn/json-editor does, but customized for our organization. JSON Schemas make it so easy to add entirely new attributes to our data models and have them consistently validated across the board. Can't imagine doing it any other way.
I second this.
On our backend we have a main service in Python and a few micro-services in Node. All of the JSON data flying between these services has JSON Schema definitions.
We've built some express.js and wsgi middleware so that for a given route you can specify "Requests to this endpoint should follow schema {} responses from this endpoint should follow schema {}." Our middleware then validates all requests and responses against these schema. This works really well for us.
On our backend we have a main service in Python and a few micro-services in Node. All of the JSON data flying between these services has JSON Schema definitions.
We've built some express.js and wsgi middleware so that for a given route you can specify "Requests to this endpoint should follow schema {} responses from this endpoint should follow schema {}." Our middleware then validates all requests and responses against these schema. This works really well for us.
That sounds nice. At my shop we have all of that except the live validation, and schemas almost inevitably fall behind.
What happens when the validation fails? Also, which end does the validation, providers or consumers?
What happens when the validation fails? Also, which end does the validation, providers or consumers?
Shameless plug - our Iglu Central is a central repository for commonly-used JSON Schemas. It's here: https://github.com/snowplow/iglu-central
You can think of it like RubyGems.org or Maven Central but for storing vendored, versioned data schemas instead of code.
You can think of it like RubyGems.org or Maven Central but for storing vendored, versioned data schemas instead of code.
Yep, it's really too bad all of these form builders out there invent their own DSL instead of using the JSON Schema standard.
Whoa, this is pretty cool. People have been trying to do this for ages. If they've been analyzing how people code, they have some valuable data to develop from. I hope they make it!
I once made a programming language with a tree editor: https://youtu.be/w5-g0Hps6bA
I had anyfix operators, so it was possible to write a program that read like english. In fact, I once got someone to write the sqrt function (inspired by the SICP) in Japanese: https://youtu.be/vwgvVpCRecE
I think this is really promising to introduce people to programming. How many times have you heard someone say "programming is so frustrating! I always misplace my semicolon." Also, not having syntax means that people can use DSLs without having the pain to learn its syntax.
I once made a programming language with a tree editor: https://youtu.be/w5-g0Hps6bA
I had anyfix operators, so it was possible to write a program that read like english. In fact, I once got someone to write the sqrt function (inspired by the SICP) in Japanese: https://youtu.be/vwgvVpCRecE
I think this is really promising to introduce people to programming. How many times have you heard someone say "programming is so frustrating! I always misplace my semicolon." Also, not having syntax means that people can use DSLs without having the pain to learn its syntax.
I think you may have meant to post this on the tree based editor post?
I'm doing something similar with serializing django forms and sending them to a react app that turns the json into a form. It's a really convenient way of doing things.
Can you provide more details how do you serialize django forms?
I could have rolled my own solution but I forked this guy's repo (fork here: https://github.com/PendletonJones/remote_forms ) and updated it to work with Python3, I also stripped out some of the stuff in date related fields because the original guy was doing some weird stuff but it's a work in progress.
Edit: basically just creating a dict out of the various attributes and then passing to json.dumps()
Edit: basically just creating a dict out of the various attributes and then passing to json.dumps()
See also tcomb-form [1] with it's tcomb-json-schema plugin [2].
We're currently using react-forms with a custom json-schema to react-forms schema conversion.
[1] https://github.com/gcanti/tcomb-form [2] https://github.com/gcanti/tcomb-json-schema
We're currently using react-forms with a custom json-schema to react-forms schema conversion.
[1] https://github.com/gcanti/tcomb-form [2] https://github.com/gcanti/tcomb-json-schema
tcomb is one of the most wonderful projects I have come across, and it works beautifully with a serialiser like transit-js.
In some sense it enables your program to resemble a type system and be able to easily serialise it at runtime. Kind of similar to how games are written, I believe. And with tcomb-form you can easily have a ui layer as well.
In some sense it enables your program to resemble a type system and be able to easily serialise it at runtime. Kind of similar to how games are written, I believe. And with tcomb-form you can easily have a ui layer as well.
I just started learning React and it's great how libraries like these are almost making the construction of front-end web components into a DSL via JSON schemas.
Was working on a similar project that I never managed to finish. I think this is a really useful tool. One thing missing is custom input widgets.
Maybe I am missing something but how are they dealing with dates?
I would assume by using ISO 8601 dates which is the closest thing there is to a standard date format in JSON.
i-JSON[1] (internet JSON a/k/a interoperable JSON) has a standard date format. Not surprisingly, it's based on ISO 8601.
1: https://tools.ietf.org/html/rfc7493
1: https://tools.ietf.org/html/rfc7493
Meteor js had this with the aldeed:autoform package ages ago
This is pretty amazing. Is it all auto-recursive?
Cool. Unit tests would be nice.
[1] http://json-schema.org/examples.html