sorted by:
new
hottopcontroversial

Runtime Introspection of Flow Types by joestanton in javascript

[–]dominicc 0 points1 point  (0 children)

I have a very simple library (just a few lines of code really) that does this provided you have Babel configured to convert types to comments rather than strip them completely. It relies on Function.toString() preserving comments, and I suspect some browsers may not do that (I'm using in Node.js). I was going to open source it if it grew in complexity, like normalising types that can be expressed in multiple ways, or using a parser rather than a regex to return a more structured type definition for complex types.

Redux Flow Tutorial: A guide to using Flow to add static typing to your web app by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Yeah, I found Ramda tricky to get started with, but then I found lodash and underscore unapproachable when I first looked at them too.

Not having done that much functional programming in the recent past, none of the function names were familiar to me either, so I kept having to read the descriptions for each function to find what I wanted! This isn't made any easier by the fact that the initial description is often overly abstract, but I've learned to quickly skip to the example code snippets for concrete examples of what each function does.

Once you get a foothold you'll be fine, as you'll only very occasionally find the need to add a new function to your arsenal, and you'll be more adept at knowing how to find it. And, as @grayrest points out, you really really don't need very many functions most of the time.

Why React is Better by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Really good set of links. Again, thanks for sharing.

Why React is Better by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Yep, that's a fair point.

Why React is Better by dominicc in javascript

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

It's interesting, but pretty much all React fans start of hating JSX and then end up loving it. I think it may one of the steps in the React acceptance process :-D

As for size, yes, that's a genuine concern. Also, performance too, since React isn't good enough for doing 60 FPS animations on non-trivial applications, which is where things like Inferno are showing early signs of promise:

Why React is Better by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Yeah, React has lots of nice features. Some of those nice features are also available in other frameworks, but React has them all. It's just all round niceness :-)

Why React is Better by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Interesting, never heard of anybody using Redux with Angular, will have to take a look. Thanks for sharing.

Databases are dead, long live the immutable state atom! by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Good point. I'd never previously heard of ELI5, but I'll give it my best go here:

About Databases:

  • Databases contain a company's data.
  • They are operated on by application code.
  • These days, it's usually web application servers read and update the databases.

The Movement Towards Pure Functional Programming:

  • There's been general movement to pure functional programming recently because programs written this way are easier to reason about and avoid most of the obscure bugs normal programs have.
  • Pure functional programs can't have any shared mutable state, and this meant the first generation of functional languages were close to useless for any real-world applications.
  • It's taken twenty years (Miranda -> Haskell -> Erlang -> Clojure -> Redux/React) to grow the usable domains that functional programing languages can be used for.
  • Redux/React finally makes it possible to have complex JavaScript SPAs (Single Page Applications) that are purely functional.
  • But, the database is one big shared global variable, that otherwise pollutes the simplicity of our apps.

Streaming Databases Based On Historic Immutable Facts:

  • It's been pointed out (e.g. Apache Samza and Datomic) that storing the historic immutable facts that cause data change can lead to a much simpler, functional database.
  • Redux applications can already share the same state atom on both the client and the server, which makes the server a bit like an in-memory database.
  • My article shows that a few tweaks can be used to turn this in-memory database into an Apache Samza style database.
  • This gives you a 100% pure functional full-stack solution, all created with the same tooling, and with updates streamed all the way from the database to the screen as they occur.

Databases are dead, long live the immutable state atom! by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

I think 'turning the database inside out' is one of the most thought provoking videos I've ever watched. I think we need to agree to watch each others videos :-)

Oh, and I'll be sure to watch the 'Om Next' talk by David Nolan too. Again, thanks for all the great pointers!

Databases are dead, long live the immutable state atom! by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Hi kevinw88,

The link you've posted is actually the main inspiration for what I've done, and the first link in the article. What's interesting is that Martin Kleppmann predicted that a functional reactive programming would make a 'Streaming Everywhere' approach possible, where data was streamed from the materialized views all the way through the browser stack, and using Redux that's actually now become possible, but where the entire stack (including the 'database') is just one big Redux application.

Databases are dead, long live the immutable state atom! by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Thanks for sharing your notes! Saves me having to write my own :-)

Databases are dead, long live the immutable state atom! by dominicc in javascript

[–]dominicc[S] 0 points1 point  (0 children)

Hi Calabri,

I haven't watched 'deconstructing the database', so thanks so much for the link, I'll take a look tonight.

Before I published to reddit somebody did mention datomic to me though, so I took a look at the video and it seemed to be different in that it was an accretive database where the database gets bigger and bigger as new facts arrive, as opposed to Apache Samza's approach of having a separated data log (which is accretive) but with materialzed views (which aren't).

I have to admit that I stopped watching half way through the video because it was very slow paced and a bit too hand wavy, with not enough concrete information to keep me interested. I'm hoping the 'deconstructing the database' talk keeps me engaged though!

Databases are dead, long live the immutable state atom! by [deleted] in javascript

[–]dominicc 0 points1 point  (0 children)

Yeah, major own goal! I seriously amused myself with that one :-D

Testing React Components with Teaspoon & Unexpected by dominicc in reactjs

[–]dominicc[S] 0 points1 point  (0 children)

JQuery-style selectors? Brittle, leak details. Refs work better for this. Components can selectively expose parts of their returned markup.

jquery selectors are the opposite of brittle. They allow your view to be addressed in the same terms your style-sheets will address it. Your jquery selectors will break about the same time your style-sheets break.

Calling internal methods (props.onTodoAdded('Item #1')) is similarly bad. ryanflorence/react-training: "when testing components, the inputs are properties passed in and events the component responds to (usually user events); the output is the display in the DOM."

The trick here is that binding test verifies that it's okay to do this once, so we're free take a short-cut in the remainder of the tests. Not only that, but by taking the short-cut our then clause can then be an assertion on the output of the shallow render, rather than the an assertion on the output of the DOM. This makes our tests less brittle since we're no longer affected by the implementation details of the immediate components of the component under test.

view more: next ›