gcanti

fp-ts [1] contains an implementation of Higher Kinded Types, which TypeScript doesn’t support natively (the idea for emulating higher kinded types in TypeScript is based on "Lightweight higher-kinded polymorphism" [2])

[1] https://github.com/gcanti/fp-ts [2] https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-ki...

for a functional library that plays nicely with TS check this out: https://github.com/gcanti/fp-ts

For my fellow italians, I wrote a free "Introduction to functional programming" PDF, check out https://github.com/gcanti/functional-programming

Here's a (partial) porting to TypeScript https://github.com/gcanti/money-ts

working on a fp library for TypeScript if you want to take a look https://github.com/gcanti/fp-ts

You could write the runtime definition and extract the static types from that https://github.com/gcanti/io-ts

This is a TypeScript compatible runtime type system for IO validation https://github.com/gcanti/io-ts

what's the state of the JavaScript backend? I do frontend and I'd really love to write some code in idris

Not sure about TypeScript but with Flow you can get HKT through some contortions https://github.com/gcanti/flow-static-land (in Elm too)

I wrote a library [1] and a babel plugin [2] (bonus point: is Flow compatible) in order to deal with those cumbersome runtime type checks.

[1] https://github.com/gcanti/tcomb [2] https://github.com/gcanti/babel-plugin-tcomb

I'm working on a babel plugin [1] that should make the migration even more gradual. At the end of the process you get both static and runtime type safety.

[1] https://github.com/gcanti/babel-plugin-tcomb

Yep. However static and runtime type checking are not mutually exclusive. Actually there's a TypeScript definition file included in the repo. Moreover such a runtime type checking brings additional features like refinement types and runtime type introspection

> I was hooked on the idea of having a type safe data record that was also immutable

Me too, thus I wrote https://github.com/gcanti/tcomb

Shameless plug: https://github.com/gcanti/tcomb. Used in development/production in several places, included the new MapBox Studio

Hi, shameless plug: another (typed) immutable data structure library, https://github.com/gcanti/tcomb. Main features:

- works with regular objects and arrays - runtime type checks - easy debugging with Chrome DevTools - immutability and immutability helpers - runtime type introspection - easy JSON serialization / deseralization - pattern matching

Also https://github.com/gcanti/redux-tcomb (Immutable and type-checked state and actions for Redux)

Hi, author here. Thanks for your kind words :)

> They often need to build forms quickly and a lot of them

I wrote a library specifically with this goal: https://github.com/gcanti/tcomb-form. React.js + Bootstrap + ARIA support. Maybe it could be integrated with react-ui-builder

set theory, equivalence relations, partial and total orders, algebra (monoids, lattices, ...), graphs

Interesting: here the key point is composability. I wrote a validation library in the same vein but using functions as representations of sets https://github.com/gcanti/tcomb-validation

> I need to be able to asynchronously get data from all kinds of places before I can even think about calling React.renderToString

You can define middlewares, as you would do server-side with expressjs:

    router.route({
      method: 'GET',
      path: '/users/:userId',
      handler: function (ctx) {
        // load user async
        getUser(ctx.params.userId, function (err, user) {
          ctx.user = user;
          ctx.next(); // exec next middleware
        }); 
      }
    });

There is a `demo` folder with a detailed example. The main entry point for the client is here https://github.com/gcanti/tom/blob/master/demo/client.js#L21

I'm also experimenting with "isomorphic" apps. I wrote a router with an expressjs/hapijs like API (middlewares included). The main point is handling the state before choosing the view. The concept is general enough to avoid being tied to React although React makes things easier. Once you have such a router, handling nested views (a la react-router) is a trivial particular case.

Here's my lab https://github.com/gcanti/tom

Shouldn't it the other way around?

1. receive an "intent" (request) 2. get whatever data that intent depends on 3. choose a suitable view

I tend of think UIs as projections of the state/model

Hello HN,

My main use case at the moment is generating tons of forms for our internal backoffice(s) (for whom the Bootstrap theme is good enough), but with the new customization feature I'm going to use this library for our customer web app as well.

I'd love to hear your feedback.

Hello, I wrote this handy little library for testing purposes: you can extract the vdom from a React component and test it against a JSON with simple tools like assert.deepEqual() and without a real DOM. The extracted vdom has the following type definition:

    type Node = {
      tag: string,
      attrs: object<name, value>,
      children: undefined | null | Node | Array<Node>
    }

If your component handle a private state, you can inject a state to test different configurations.

This is an example of massive use in a form generation library:

https://github.com/gcanti/tcomb-form/blob/master/test/test.j...

Hope it can help you too.

Om is an amazing and inspiring project! thanks for writing it.

> Lack of update is a show stopper

Well, it's quite easy to write something like Facebook Immutability Helpers [1]. As you correctly stated, it really depends on your own use case and performance issues.

I'll try some perf experiment with [1] or something similar to see what comes out.

[1]: http://facebook.github.io/react/docs/update.html

What do you think about vanilla `Object.freeze`? Any drawbacks? Here my considerations at the moment:

Pros:

- you can use native data structures instead of continually wrap / unwrap

- you can use native methods on them (map, filter, ...)

- hence (almost) no interoperability problems with other libraries

- overall your coding style doesn't change so much

- (possible perf gains since the js engine knows the object is frozen? - I really don't know)

- EDIT: 0KB dependency

Cons:

- you must find / write a way to update efficiently

> One reason for this change is to make it possible to use object literals or record syntax where that is more appropriate than function calls

I think this will be the most revolutionary aspect in the next months, both for development and tests. I wrote an article explaining why I have this opinion:

https://gcanti.github.io/2014/10/29/understanding-react-and-...

> Something I would rather enjoy, would be a carefully, curated list of verified great resources for React, not a random list of everything React.

Discovery is a problem for users and also for authors. I wrote a form library https://github.com/gcanti/tcomb-form but I really don't know how to promote it other than add the `react-component` keyword (for [1] ) and list it on [2].

[1] http://react-components.com/

[2] https://github.com/facebook/react/wiki/Complementary-Tools

> Another options besides comment-based annotations is property based annotations. Basically provide a library that contains all the possible primitive types that can be checked and functions for composing higher order types.

Shameless plug: I wrote a similar library based on set theory (I'm a mathematician)

https://github.com/gcanti/tcomb

EDIT: and here an article explaining the rationale behind the library

https://gcanti.github.io/2014/09/29/javascript-types-and-set...