Gotta love JSON. It's XML without the tools so you get to reinvent everything to pad your resume.<p><pre><code> XML -> JSON
WSDL -> JSON schema
XPath -> JSON path
XSLT -> JSON template?
SOAP -> Swagger and friends
</code></pre>
One or two decades from now there will be too many tools and things to learn about JSON so another generation will reinvent a new "perfect format for everything". And a new cycle will have started.
I think there's a lot of useful unexplored territory in this sort of tool. So much work nowadays is happening in maps/dictionaries/what-have-you, with a lot of work being, essentially, data shape transformation.<p>Despite this, many languages aren't great at this! we have tools that work alright on first-order operations but fall apart on higher level things.<p>Even really simple things like "conditionally include a key" are rarely supported in a way that leads to concise code. How many times have we all written<p><pre><code> foo = {...}
if bar:
foo['a'] = x
</code></pre>
instead of something like<p><pre><code> foo = { ... , 'a': x if bar }
</code></pre>
and then having bugs because of branches? Tools that solve this sort of problem will be to modern programming what things like the Unix shell was to data mungers in the past.<p>Haskell lenses kinda goes into this stuff, though Haskell itself is a bit hard to use in a lightweight fashion. Clojure has Specter. But still looking for some more stuff to fill this hole, especially in the "transitionally typed" stuff like Typescript or Python + Mypy
What's wrong with:<p><pre><code> return {
labels: data.items.map(function(value){
return {
type: "label",
value: value > 10 ? value : value * 100
};
})
};
</code></pre>
I hope your project does not get too popular.
This seems pretty interesting, and I will be happy to play around with it.<p>I am a bit concerned that there is no discussion in the docs of the potential security risks of allowing direct native JS execution of arbitrary instructions passed in by an untrusted source.<p>I use a project called JSONLogic (jsonlogic.com) which bears some similarity to ST in terms of being able to select and transform values. The biggest advantage I see with it is, unless you explicitly plug in a rule that parses and executes user data, there is no way for the data to "escape the sandbox". This means you can safely build a query syntax on top of it where you can directly consume the arbitrarily complex query from an untrusted source and execute it in a secure manner.
Hi, my name is Ethan. I'm the creator.<p>I thought I would provide some context on why I wrote this library, and how I'm using this right now. So here it goes:<p>Other than ST.js, I also work on another open source project called Jasonette (<a href="https://www.jasonette.com" rel="nofollow">https://www.jasonette.com</a>), which lets you write an entire native iOS/Android app in nothing but JSON markup.<p>And when you can express the entire app logic--from model to view to controller--in JSON, you can split them up whichever way you want and load them from anywhere (from a file, from cache, from a remote server, or from local memory).<p>But the biggest benefit of all is: you can load an entire ios/android native app from the server in realtime, just like how web browsers load HTML/JS/CSS in realtime.<p>When working on Jasonette, implementing model and view was relatively simple. For model it's natural since JSON is all about describing data. For view i just needed to come up with a syntax to describe layouts and all the standard mobile UI components in JSON.<p>However the biggest challenge was how do i actually describe functions in JSON. Without a function, it's just a mockup and won't really do anything meaningful.<p>Which brings us to ST.js.<p>When you think about what a function is, it takes one value and turns it into another. So basically what I needed to do was build something that will take one JSON, and turn it into another JSON, but most importantly I would have to do it using JSON. Basically I needed to implement a finite state machine in purely JSON.<p>And this is what templates do. So I set out to build a JSON template engine that turns one JSON into another using a template which itself is written in JSON.<p>What's really cool about this is, since the template is JSON (As far as I know there doesn't exist any prior art that uses JSON as a template, otherwise I would have used it instead), it has all the benefits of the JSON format itself:<p>1. You can store it anywhere (Most DBMS nowadays support JSON natively)<p>2. You can send it over the Internet<p>3. You can compose them easily<p>4. You can validate them using JSON schema<p>5. etc.<p>To use a more specific example, I use ST.js in both Android and iOS versions of Jasonette as the template engine. And a JSON template is absolutely necessary in this case.<p>For example, if I want to take a piece of device-generated data and render it, I need to be able to somehow parse it client-side (can't send it back to server to re-generate a JSON) <a href="http://docs.jasonette.com/templates/#3-device-api-generated-data" rel="nofollow">http://docs.jasonette.com/templates/#3-device-api-generated-...</a><p>This also applies to many cases where the client-side data contains privacy-sensitive data. The only way to dynamically parse something that happens on the client side is by writing the template itself in JSON and sending it over as data.<p>Anyway, I hope you guys take a look at the examples on the homepage to get a glimpse of what makes ST.js powerful. Each example is almost its own library, except that you don't need a separate library for those purposes since all you're dealing with is JSON.
Have you considered reaching out to DevOps folks to consider something like this for complex configurations?...There are related solutions such as jsonnet/ksonette but I think something like this might be preferable.<p>I work on a similar problem though using a UI based approach, I gave a demo to the Kubernetes SIG App group a while back which be found here: <a href="https://www.youtube.com/watch?v=alEzE8MSNaI&t=30m" rel="nofollow">https://www.youtube.com/watch?v=alEzE8MSNaI&t=30m</a><p>Btw Ethan, maybe my email is landing in your Spam folder? I've tried reaching out :)
Currently I'm having issues trying to figure out a new stack where we can't figure out where to put the backend for front-end logic in a React App over the top of GraphQL. I've been thinking of implementing something like this as the transforms or the formatters don't make a ton of sense to be on the client or the API or in GraphQL and I'm loathe to make another API call in the chain as it feels like I there's enough of those already?<p>Would that be a good use case for this?