Hacker News new | past | comments | ask | show | jobs | submit | more d4n3's comments login

PureRenderMixin is basically shouldComponentUpdate with a shallow comparison of previous/next props and state, but the big win is avoiding render and diff for the component, so returning false would be about the same as PureRenderMixin.


PureRenderMixin would defenitely help here, even to the point where it's comparable with the js solution.

Even though keys help here, render is still called for every image every time and then diffed.

He'd have to extract the image divs to a component and put PureRenderMixin on it so that the component's render is skipped altogether.


For me it was trying to index a huge folder containing images, you can use project settings to exclude some folders with the folder_exclude_patterns setting.


I think modern browsers prevent cross-requests to local subnets so this may mitigate CSRF


It's way better to use [values].join('') here... It's probably faster and it coerces all values to string.

If the first couple of results were numbers or booleans, they would be summed:

    > true + 10 + " result"
    11 result

    > [true,10," result"].join('')
    true10 result


All the functions in that code return numbers.


Making [`.reduce`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) a significantly better choice.


Ah ok. At first glance it looked like he was putting together something like an url.


Javascript has "semicolon insertion".

It tries to parse a newline with no semicolon as continuing the current expression, if it can't, it inserts a semicolon.

It's a 'feature' that's caused too many bugs and is a warning in most linters.


Jshint catches this with 2 warnings: missing semicolon and expected assingment or function call.

In Sublime text 3, you can have inline warnings and as-you-type linting with the sublimelinter jshint plugin:

https://github.com/SublimeLinter/SublimeLinter-jshint


I love this quote in the comments:

> when you have REPL you are TDD’ing in a different way as opposed to constructing persistent unit-test classes that could potentially form a layer of cement.

Lately I've been using the console for development in rails and javascript more than anything and it is a really good way to iterate on a solution quickly.


It's great for quick feedback. It's less good when your coworker breaks the build on a less-used codepath because there are no unit tests to run.


Bingo.

Especially in a functional language, if you architect your code well, e.g. avoiding large (lengthy) functions. You write a function, test it in the REPL, and forget about it. Until, of course, someone hands it data you weren't expecting. But here Clojure helps you a bit with it's effort to provide consistent interfaces to its collection types, e.g. lists, vectors and maps. And the most expressive and fast to write code in, the more time you can devote to testing.

I'll bet in practice this sort of TDD works very well, as long as your coders are diligent. For the projects I've done this way, including a couple in C using a very good but now defunct interpretive environment for it (CenterLine's CodeCenter/ObjectCenter), it's been superb. In an extreme case, I spent around a week programming in C the engine of a high speed document imaging scanning system, at which point I got the driver that let me speak directly to the scanner. The first time I tried it end-to-end it worked ... until I ran out of file descriptors (had forgotten to close() each file after writing out its contents).

There was of course a whole lot of experience that made that feat possible, but I found it very impressive how the environment allowed me to write code with so few flaws (that was, in fact, the only major one I can remember once I declared a function finished and ready to try out for real).


Wow, that was exactly what happened to me... Everything is so sharp and square here.


> you'll want to replace them with code written in the native language

Probably not true for Javascript (and other scripted languages) - matching regex uses native and highly optimized regex lib, which will usually be orders of magnitude faster than implementing this in the language.


That isn't relevant in this context as the library linked couldn't be integrated into JavaScript.


Sorry, which library do you mean? The OP is a javascript library..

I just wanted to point out that regex is much faster in javascript than doing things 'by hand'.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: