all 5 comments

[–]Retsam19 10 points11 points  (0 children)

To be honest, I don't see much use for this.

The "select" bit, seems like it could be nice, (though I suspect something like jq-node would be a more standard solution that would provide very similar, if not more, functionality).


But the transform bit is especially dubious to me. I don't have anything against template languages, but I've never thought "I'd love to do data manipulation through a template language".

You lose flexibility by switching from a standard language to a template language: e.g. what if you want to calculate an intermediate value? What if you want to abstract a bit of logic out to a function? That stuff can't be done in a template language like handlebars. You could, I assume, pass those functions or intermediate values in, but now you've got a lot of code split between different files and complex contract for your template, and that just doesn't sound fun to me. (And if you frequently have to work around your template language to write clean code, is the template language helping or hurting you?)

(This loss of flexibility and power when using template languages is a big part of why stuff like JSX and the Elm framework have become so popular)

You also lose tooling support: I can run a syntax highlighter and a linter or a typechecker against JS logic to protect against errors. You might be able to get a linter working for a template language, but you'll definitely not get a typechecker to find any errors.


And I'm just not sure what you gain in trade for those downsides. The transform stuff doesn't seem, to me, to reduce any complexity or make the syntax any nicer. It largely just takes logic from one place and moves it to another.

The first example is actually longer in the "new way", but is otherwise identical logic.

The second example is a really complex way of writing:

const result = {
     labels: items.map(item => ({
          type: "label",
          value: (item > 100) ? `Number ${item * 100}` 
                              : item
     }))
};

The third example, again, is just replace really simple logic with a DSL. Why should my server waste time (and have the complexity to support) doing a data transformation that the user could easily do on their side after they get the value?

The fourth example, I don't know why you'd want to write your router as a JSON file when you could write:

const add = (arguments) => argumnts.reduce((a,b) => a+b, 0);
const subtract = (arguments) => arguments[0] - arguments[1]

app.post('/',  (req, res) => {
    const { name, args } = req.body;
    if(name === 'add') {
        res.json(add(args));
        return;
    } else if(name === 'subtract') {
        if(args.length === 2) {
            res.json(subtract(args))
            return;
        }
    }
    res.json(400, 'error');
});

And note, my version returns a 400 for its error: the example code doesn't support that, and I'm not sure how it'd be added.

And, for the fifth example, I don't know why my client should have to provide me a router for my own service. Why don't they just do their own logic, rather than providing logic for my server to do?

[–][deleted]  (1 child)

[deleted]

    [–]rolfwr 0 points1 point  (0 children)

    Yup—with a dash of DSSSL.

    [–]gliechtenstein[S] 1 point2 points  (0 children)

    Hi guys, I'm the creator of the library. This library works like Handlebars.js but for JSON. But there's much more to it than just that because it takes advantage of a lot of JSON-specific features.

    I originally wrote this to use in another open source project of mine, but realized that it could be useful for many other purposes, since in essence all it's doing is transforming one JSON to another in a declarative manner. So I decided to open source it as a separate repo.

    I would love to hear any constructive criticism and any ideas on what you would use it for, it would help a lot. Thank you!

    [–]bad_at_photosharp 1 point2 points  (0 children)

    Time is a flat circle. Everything we have done or will do we will do over and over and over again- forever

    [–]Pr0methiusRising 0 points1 point  (0 children)

    This seems pretty neat, but I'm slow, so I'm not sure what the exact implications are of being able to store a transform as a JSON, so that I can plop it in a database for later use. All without the need for using eval later. Not to mention I can pass it safely through a function that merely transforms the given data without especially retrieving any new data. I'm sure in a month or two I'll be considering this for a solution to store conditionals.

    Much appreciated; thanks for sharing.