Editor

[mathiasrw]

Any plans to open a repo where people can contribute with code to an drag-and-drop kind of editor of the JSON for Jasonette?

[gliechtenstein]

Yup I have a private pet project (just whipped it up on an afternoon) that takes a JSON markup and turns it into

s, styled with CSS flexbox. It works good enough, but as I said it was just an experiment so I think I need to polish it up a bit before releasing.

That project was just written in html+jQuery+css and currently i'm looking into other options since using jQuery becomes messy quickly. So far I'm considering react.js and vue.js. I think there are pros and cons for each.

Please feel free to jump in and share your thoughts.

[elenduuche]

I think you should open it up and get inputs from guys, draw up a roadmap sort of, and then allow guys get to work.

[mathiasrw]

I agree with @elenduuche - get it up and out - bad code or not - we all had side projects.

Lets get the code awesome tegether.

Personally I like ractive.js and vue.js

[gliechtenstein]

OK I will try to get it out as soon as possible :)

Just want to clarify that it won't be a fancy "drag and drop editor" right out of the box. I'm talking more on a foundational level.

There are a lot of things involved in this technology, such as json-to-html renderer, json templating, and maybe even server-side rendering. I will try to break them down to pieces and start releasing them one by one as library, each one will build on top of another via require.

When all these are combined, it will be easy to just require them and build a drag-and-drop editor.

Anyway, I will keep you posted. Stay tuned!

[gliechtenstein]

Just had a conversation on HN thread and thought this was interesting. Posting here for future reference https://news.ycombinator.com/item?id=12880704

The advantages of creating your own wysiwyg editor is that you can control exactly what functionality Jasonette supports and allow developers to create views across different platforms (right now Xcode is Mac only). But have you considered starting with Interface Builder and creating a tool to convert IB views to JSON? Interface Builder is home to a lot of developers who already understand how to use that tool, asking devs to work in a new half baked editor would probably be frustrating and add more complexity/moving parts which is your enemy as a new project/endeavor.
If you create a tool that just converts IB views to JSON you can demonstrate progress much faster and learn and experiment with what the requirements of the final editor are. It will be much easier to stand up and way less effort than maintaining your own editor codebase while the project is young. Your time is the most valuable thing you have so don't spend it creating a new editor which could be its own project in itself. You want to put it towards expanding missing functionality between JSON and native components. One day when you find success and if you really still need to limit the user you can move all the functions you made for converting Interface Builder views into your own custom editor.
I think first thing I would do is take a very complicated interface view from a native project and analyze the view hierarchy and report errors to the user like "Warning: Nested UITableViews are not supported in Jasonette", "UIButton delegate will be ignored", etc. Then once you create this sort of 'unit test' that the IB is well-formatted you can then go about exporting it to JSON.
There may be a world where you actually are able to use all of the functionality of IB and don't ever have to have your own editor.

[mathiasrw]

Is the interface builder this one? https://developer.apple.com/xcode/interface-builder/

I looks awesome. I would never start there if I was not familiar to IB.

Please post here if you release your test project in a new repo.

[booc0mtaco]

@gliechtenstein I humbly suggest giving json-editor a look. I'm working on a different project and built a schema for a JSON input type, using the schemas this tool uses. I could help write up the schema for JASON, and you get all the functionality that's listed in this plugin for free. Of course, like all OSS work, it could be forked or changed to support your needs here. :) Thoughts?

check out the demo of json-editor! Something like this could be used with any of the other mentioned approaches (electron app, hosted web app, etc.)

[gliechtenstein]

@booc0mtaco this is a cool approach! Would this mean, with just a schema we could:

1. have a form where people fill out what component they want to add
2. style them
3. handle nested components
4. and turn them into a single JSON?

I'm especially curious about the nested part--that would be cool to create a complex layout just using the schema

[booc0mtaco]

@gliechtenstein Exactly. With a good schema-based editor, you can also make inflexible values (those operating as enums) behave as such. And enforce the structure a bit. The plugin for Atom isn't so great based on my last use, but there might be others. Either way, a schema is a good idea, I think!

You could also lock the schema updates to each release. This would automatically provide validation for changes, and expose interface for new/updated features. Just a few ideas.

[thedumbtechguy]

@booc0mtaco a schema is definitely needed. The work would be appreciated!

This would allow people to be able to even validate their Json before publishing
It would tremendously help with porting Jasonette over to different platforms.

[gliechtenstein]

I agree that this would be great, the validation feature sounds great and is something we need. I can imagine this tying into documentation someday in the future.

It would be awesome if someone creates this. I personally won't have resources at the moment to work on this but you are super welcome to build it and share with us!

At least a primitive version would be great to get going.

[booc0mtaco]

@gliechtenstein @frostymarvelous I'll try to carve out some time in the next few weeks to take a stab at it. Will let you know the results!

[gliechtenstein]

@booc0mtaco looking forward to it!

[booc0mtaco]

FYI, on this one...

I've seen a lot of stuff that would cause flux in a schema editor. Is there some documentation that annotates all of the functionality so far? On issues opened recently, I've noticed a growing list of $-based keys, so I'm thinking I'll wait a bit for the dust to settle before I dig into this.

Once we have a workable schema, it would be much easier to update it with feature additions :) And an editor that consumes it would automatically work with the updated schema file.

[gliechtenstein]

@booc0mtaco Here's the documentation https://jasonette.github.io/documentation/

To clarify, most of the API specs are in the documentation (with exception of some undocumented ones which are sometimes intentionally left out for various reasons) and while you're right that it will keep growing, I doubt that they will grow in a way that will break anything.

There have been some discussions on adding "advanced" attributes (example: #43) but these are "advanced" features and I doubt we will change much about existing APIs.

I still do think it would be useful to have some sort of schema, and I think the whole point of having a schema is to have a versionable way to maintain and document the APIs, so I think it's even more valuable even when we consider that the API will have more additions in the future.

Also, I already have lots of apps running on this exact API and they are working just fine. I designed the API based on my actual usage and not based on an esoteric philosophy about how things should work so I strongly doubt there will be situations in the future where we find out something doesn't work with the current grammar and will need to overhaul.

The last factor in this is I'm currently working an Android version based on the existing API. This means it would be foolish to try to overhaul the existing API when it's working just fine. We've covered pretty much all kinds of mobile UI use cases with the current API and I spent a couple of months just documenting and writing examples for the API, and the result is I am confident we don't need to change much (except for adding more advanced features, but will make sure these don't break anything)

Bottom line, at this point I don't think we need to worry much about the potential risk in the future API changes. Hope this makes sense. Let me know what you think :)

[booc0mtaco]

@gliechtenstein sounds great! I hadn't pored thru the existing API, so from my view, the issues were about new and exciting things appearing :-) Thanks for the clarity. (RE: "undocumented" API parts, an editor app wouldn't expose options to add those, but an enterprising dev could take the JSON it outputs, and go crazy if they wish).

All that being said, I think we might be good to go then. I may host something like http://jeremydorn.com/json-editor/ on my own site, just to see how people like it. If there's appetite, taking that and building a Electron App might be an option, or hosting something similar directly from a JASONETTE page might also be suitable. Thoughts?

[lukeramsden]

@gliechtenstein @booc0mtaco I can help if a repo gets made :)

[gliechtenstein]

@booc0mtaco Sorry! i totally missed the last comment, my fault. I think this sounds great. And thanks for resurfacing this @lukeramsden

[lukeramsden]

@gliechtenstein (☞ﾟヮﾟ)☞

[booc0mtaco]

New year; new ambitions! I'll get the ball rolling on this by the weekend crosses fingers. @lukeramsden keep an eye out for a new repo. I'll probably take the approach from my last comment, and host a github page to get MVP for this.

cc @gliechtenstein

[lukeramsden]

@booc0mtaco Looking forward to it!

[booc0mtaco]

@lukeramsden to keep myself honest 😄

[lukeramsden]

@booc0mtaco Thinking about it, wouldn't it be better to be under the Jasonette organization? Maybe you could transfer it (you'd have to talk to @gliechtenstein) over? Also, make sure you're in the slack channel, its the usual place for discussions.

[booc0mtaco]

@lukeramsden probably so (noticed it was an org as I was referencing it in the README). For now, I'll leave this repo alone, jump into y'alls channel, and see what makes sense :) I can imagine several approaches to this, so IMO not sure if we want to commit to any particular one officially (pardon the pun!).

I've somehow managed to not use slack yet 😮 , but might as well start somewhere .

EDIT: a transfer should be possible, no? another thing to discuss later on

[lukeramsden]

It's very simple, I'm sure youll figure it out. I'm lukeramsden, @gliechtenstein is ethan

[gliechtenstein]

@booc0mtaco yeah please join slack! Looking forward to this :)