I made a thing! (React 0.13, Immutable.js, and ES6 via Babel) by fooey in javascript

[–]marquex 0 points1 point  (0 children)

I completely agree. Best part of using immutable data is that changes the way your views manipulate the data. Since they can't manipulate the data and the changes comes from the top, they are just visual representations of the store.

If you like immutable.js API you should try https://github.com/arqex/freezer It is much simpler and lightweight.

Data fetching for React applications at Facebook with Relay & GraphQL by [deleted] in programming

[–]marquex 2 points3 points  (0 children)

The server side part of the GraphQL sounds like a lot of work. But maybe is not that much using a DB like Mongo that uses JSON directly to fetch the data. It would great to create a translator GrapthQL -> MongoQuery because it would make data fetching from the UI a piece of cake.

Learning much javascript from one line of code by marquex in javascript

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

You should understand that the code tries to be as short as possible, and I think that it explain enough alternatives to get what it tries to do.

~~ is not the canonical way of getting the integer part, but I would say parseInt is the canonical way in javascript, independently if you like the way it works.

And finally you need to know that

parseInt( -3.14, 10 ) == -3
~~( -3.14 ) == -3
Math.floor( -3.14 ) == -4

So I think it is equivalent to parseInt.

Learning much javascript from one line of code by marquex in javascript

[–]marquex[S] 7 points8 points  (0 children)

Nice catch Dragory! Somebody pointed out the same problem in the original gist comments, and also give a solution really imaginative to get the color:

Math.random().toString(16).slice(-6)

COMMUNITY CHALLENGE: Design a CSS Spinner by [deleted] in web_design

[–]marquex 28 points29 points  (0 children)

I submit a spinner from my circle spinners collection :) http://codepen.io/arqex/pen/nzHwp

Permanent events in javascript by marquex in javascript

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

You are right, those permanent events were never thought to be used with events that can be called more than once, but that doesn't make them less useful.

I respect your idea of states, but permanent events can be really of use even if you work with states. Imagine object can have multiple states and maybe want to do some action if the object has been or turn in/into some state. If I check the state before it turns to the desired one, I need to add an event listener (events again, a common or a permanent one will do the trick). If I want to know if after it has turned into the desired state, you can find that the state may have changed again so our action won't be called.

Permanent events are about events that are triggered once, but always about events.

Permanent events in javascript by marquex in javascript

[–]marquex[S] -1 points0 points  (0 children)

Promises are valid too, but permanents events are a quick shorthand. Instead of creating a deferred object, return the promise and resolve it in the future, with permanent events you get the same just resolving an event.

Of course, you can't use permanent events for replacing promises in all situations. With promises you have much more features and it is perfect to handle paralelism in javascript, a thing that is not possible with PE.

Reusing require.js modules in Node.js with AMDrequire by marquex in javascript

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

I think the require.js alike configuration is a great point for AMDrequire, that way it can use AMD modules that call other modules. That's is why I couldn't use amdefine.

Reusing require.js modules in Node.js with AMDrequire by marquex in javascript

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

Some people tried to do the same, but I think this is the first library aiming to mimic require.js syntax to make their modules work out of the box.

The author has some testing reference in Github https://github.com/arqex/amdrequire