HN Explorer

7 comments

[ 2.9 ms ] story [ 22.6 ms ] thread
marcosdumay
> What if your domain model could validate the UI for free?

Then your domain modeling language will be as detailed and error prone as the UI designing language, and completely unsuitable for the task. As the article exemplifies.

Abstraction and detail are at odds against each other. You simply can not have both.

Also, why verify the domain description? You must check that the UI fits the problem, not a short description of it.

bshimmin
The tcomb library seems to do quite a lot, some of which might be sort of useful, but the example supplied here doesn't really seem to support why you might use it. The code in fact just seems weird to me: if you're having to use a try/catch to do some really basic form validation, then obviously that's horribly wrong... but the example below, under "Further Reading", which is (I think?) proposed as the better solution, doesn't really seem any different from how you might go about solving this problem were you not to use any library at all, except you wouldn't have the struct stuff. Very unconvincing, if you ask me.

Contracts.js is quite a different approach, maybe even to an orthogonal problem, but perhaps is more interesting: https://github.com/disnet/contracts.js

keithnoizu
What if you could sell your one measly old cow for three magic beans. ;)
couchand
I think this looks pretty cool; I like how simple and general the last validation function is. If you're generating the UI from the model all the better (it looks like there's a note on this front at the bottom of the tcomb.js readme). This would be remarkably easy to do with React, and it all could be abstracted into a simple configuration framework.

Looks like there's a typo in the last example: you probably want to use the Struct param in the fetch function rather than explicitly creating a User.

Seems like the makings of something like Bootstrap for domain models here. Neat.

gcanti
> Looks like there's a typo

Good catch! thank you, I'll fix that asap.

As you've pointed out, I am excited by the opportunity to implement this cycle

    Domain (tcomb.js) --> UI generation (React.js, with validated props)
            ^                                  |
            |                                  |
            |                                  |
            +-------------------------- Input validation
Some example off the top of my head

    |     T    | input                  |
    +----------+------------------------+
    | Str, Num | textbox, textarea      |
    | enums    | select, radio          |
    | struct   | form                   |
    | list(T)  | table of T (recursion) |
insin
To address the "explore using tcomb with React.js" point in tcomb's README, you'll find that it's a perfect fit, so go for it! Already having immutable instances all-but guarantees an easy performance boost down the line, and React's rendering takes so much fluff out of displaying and redisplaying forms in any state. Just have a component give you a callback to let it know when state has been updated and it should be easy enough to integrate.

I switched my port of django.forms away from using my own DOM library to generating React components: https://github.com/insin/newforms

couchand
I've seen your newforms library before and been interested but I got frustrated trying to read through the examples. The leading commas are so distracting! Sorry to harp on a minor point.