gcanti

9 ms·

31.
by gcanti 12y ago
> 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:
32.
by gcanti 12y ago
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
33.
Show HN: Assert library for AtScript(github.com)
1 points by gcanti 12y ago|0 comments
34.
by gcanti 12y ago
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
35.
by gcanti 12y ago
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 we
36.
Show HN: Tcomb-form – React.js UI library for developing forms writing less code(gcanti.github.io)
5 points by gcanti 12y ago|1 comments
37.
by gcanti 12y ago
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
38.
React-vdom upgraded to React v0.12.0(github.com)
1 points by gcanti 12y ago|1 comments
39.
by gcanti 12y ago
Om is an amazing and inspiring project! thanks for writing it.
40.
by gcanti 12y ago
> 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 expe
41.
by gcanti 12y ago
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, ..
42.
by gcanti 12y ago
> 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 an
43.
Understanding React and reimplementing it from scratch(gcanti.github.io)
5 points by gcanti 12y ago|0 comments
44.
by gcanti 12y ago
> 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:&
45.
by gcanti 12y ago
> 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 p
46.
by gcanti 12y ago
Unfortunately I do not know so well Haskell to give you an answer. I was referring to this: > I think this is because there is yet to be a language that makes expressing complex types easy. Since I'm obliged to use a dynamic langua
47.
by gcanti 12y ago
Probably you are right, but for a library I think it should be an obligation to provide 100% coverage. For a generic program, maybe I sould provide 100% coverage at least of the "critical paths".
48.
by gcanti 12y ago
> I'm generally a proponent of "strongly typed" languages. But I do worry about the cognition overhead the syntax causes, and I do wonder if there is a "better way". What about dynamic language + runtime type che
49.
by gcanti 12y ago
I think there is no "proper" difference. For what I understand it's only a practical way to have a segregated state only the component is interested of. React.js is a valuable precursor but I hope we'll have something di
50.
by gcanti 12y ago
> "comprehensible" is a relative thing I agree and I hope my pragmatic side will be disproved soon :)
51.
by gcanti 12y ago
When I see concepts like transducers I'm always torn in two: my theoretical side is really excited: reducing (pun intended) a bunch of different operations to a minimal set of basic, composable operations is an awesome intellectual
52.
JavaScript, Types and Sets (Part II) and a Side Note on React.js(gcanti.github.io)
2 points by gcanti 12y ago|0 comments
53.
Introduction to set theory with JavaScript(gcanti.github.io)
5 points by gcanti 12y ago|0 comments
54.
Six reasons to define JavaScript constructors with only one argument(gcanti.github.io)
11 points by gcanti 12y ago|0 comments
55.
JSON API Part 2: validation in Node.js with type combinators(gcanti.github.io)
2 points by gcanti 12y ago|0 comments
56.
JSON Api deserialization into an object model with tcomb.js(gcanti.github.io)
6 points by gcanti 12y ago|0 comments
57.
by gcanti 12y ago
I am very happy, I can not wait to get my hands on
58.
An alternative syntax for React propTypes(gcanti.github.io)
5 points by gcanti 12y ago|0 comments
59.
by gcanti 12y ago
Lately I've seen on HN a few attempts to add runtime type checking to JavaScript. I'm happy with that, as in my experience adding a bunch of asserts in strategic places can really speed up prototyping and development, you become m
60.
by gcanti 12y ago
Thank you! author here :) in the next few days I hope to add more constraints. My main concern about react-bootstrap is the massive use of `transferPropsTo`, from what I understand is a deprecated method

More ›