jamesgt

Inspired by the great answer of Onur Yıldırım implemented with CSS variables.

I'm working on a JS lib that makes zones in an overlay to any HTML element. With two modes (edit and view) you'll be able to draw and store polygons without coding and then use them somewhere else. Like in your home automation's floorplan where you want to handle actions by just clicking to your night stand light, or zoom into a room, etc.

Author here, just an old project finally finished and published. It'll be used in my other project soon :)

If you like it please discuss here or open an issue.

Ok, yes, I agree, but can you please point out how you can store and query/filter on map contents with not predefined keys in GraphQL?

Thanks for the feedback.

I see now that regex may be an overkill, the main intent was to support keys that are not predefined. It is easy to imagine a data set where a lot of keys can exist with the same prefix: { "text-decoration": "underline", "text-decoration-color": "red", "text-align": "center" } For this situation it may be useful to query all the keys with prefix "text-", without exactly knowing what are the possible keys. Since document databases and JavaScript are popular, we should open up the strict typing. Clients may have the right to store arbitrary metadata on their objects. In GraphQL you have this option, just add a metadata key as string and you can dump anything there, but this way you lose the option to filter on this. That exact missing feature inspired jrGQL.

1. Yes, it is not a new language, since it is always a valid JSON. This is useful since every validator, syntax highlighter already knows it. GraphQL created a new language just because they not considered to reuse an existing one. You can say that jrGQL still needs parsing on top of JSON, but every query should be validated on the server side and that needs parsing too. Also we can call regex evaluation as parsing, but this is just a more by a substring() call than simple equality check to filter the result set.

2. Coloring is definitely a mistake, I'll fix it. I did not want to say that others are bad in anything. Man, those are production ready quality and this thing is just a concept with only a reference implementation. I just wanted to show where jrGQL is different from others.

3. This is about tastes, I should add that for me it is more readable. I don't like GetAllTheThingsQuery stuff, since it is defined by an other party, if you need that it is an other endpoint and you get what you were meant to get, but no control. With jrGQL you always get what you requested, so it is not WYSIWYG, but WYRIWYG.

I'm not saying it is negative. Probably I should not color red the background in the table.

I just wanted to point out where jrGQL is different from others.

Thanks for the feedback. I've seen Falcor once, but will check it again. It should probably be added to the comparison table.

Where you want to store not predefined keys in your objects.

Thanks for the feedback, can you expand a bit what you mean by nested/denormalized anti-pattern?