On MobX Redux dilemma

Leave a reply

In my experiences using MobX as a state management library produces less code and lets you get things done quicker (two-folded knife!) but with Redux you get a lot of stuff for free – most notable is scalable approach to architecture and maintenance of web applications.

I personally prefer Redux also because it’s functional like React which puts a lot of emphasize on functional stateless components and it makes me feel like a JavaScript developer. While that means it’s more verbose, it contains minimal abstraction and thus is easier to debug.

Wolf Children review

Leave a reply

Japanese Wolf Children from 2012 may seem like a cartoon but this two-hour long animated movie deals with pretty adult themes.

It centers around mother who raises her two children in a remote house under the mountain and in the absence of their father. She’s doing everything in her power to learn new things and how to provide for her children despite their secrets which can make their life a lot more tougher if the world finds out about it.

I have really enjoyed the movie, also because the animation was really well made. It looked almost real, it did a good job mimicking the real world, especially nature movement.

It’s one of these movies that are excellent but completely overlooked. If you don’t know what I mean, just watch it first and than go to IMDb and note its score and number of votes.

New React Context API

Leave a reply

I like new react API for creating and using context. It feels right. One thing I immediately tried to do was creating a helper which simplifies consuming multiple contexts. Because they create context hell. When you component uses more than one context and because of a children as a function pattern (which is basically the same as render props pattern where component’s children function is specified as a component’s prop named render), code gets familiar indent to the left (callback hell).

For example with the use of this helper,

<Theme.Consumer>
    { theme => (
        <Language.Consumer>
            { language => (
                <App theme={theme} language={language} />
            )}
        </Language.Consumer>    
    )}
</Theme.Consumer>

would become

<Consume contexts={[Theme, Language]}>
    { (theme, language) => (
        <App theme={theme} language={language} />
    )}  
</Consume>

But after giving it a second thought, I realized in high-performance web applications this “multiple contexts consumer” case scenario can be a bad idea in most cases. Because If we have for example two contexts that are always used together, it’s better to just have one context anyway. But if a component uses more contexts which aren’t co-dependent, that means parts of component will be re-rendered unnecessary. So the component should be split into components which uses only one context or co-dependant contexts.

If you are interested in Consumer component, you can see it in following snippet with example usage. I’ve also added Provide component which mirrors Consume component for the sake of completeness. It’s no problem though if you specify Providers separately or not at all – in that case it will use context’s default value than).

Goroutines don’t panic if channel they write to is gone

Leave a reply

Couple of months ago I wrote an article about error handling in concurrent Go programs. One concern I had about it was if other goroutines would panic if some goroutine produces an error value which causes return from function when the channel is iterated with range construct.

So I made another program that mimics scenario. It spawns couple of goroutines, each taking a second more to complete than previous (for the sake of test being easier to observe). When done, they write to channel. 5th goroutine returns an error (after 5 seconds) via channel which is iterated using range. In case of an error, it’s returned from function.

package main

import (
    "errors"
    "sync"
    "time"
)

type data struct {
    err  error
    data int
}

func someWork(dataChan chan<- *data, collection []int) {
    var wg sync.WaitGroup
    l := len(collection)
    wg.Add(l)
    for i, e := range collection {
        go func(i, e int) {
            time.Sleep(time.Duration(i) * time.Second)
            var err error
            if i == 5 {
                err = errors.New("error")
            }
            dataChan <- &data{err, e}
            defer wg.Done()
        }(i, e)
    }
    wg.Wait()
    close(dataChan)
}

func someFunc() {
    collection := []int{1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}
    dataChan := make(chan *data)

    go someWork(dataChan, collection)

    for c := range dataChan {
        if c.err != nil {
            return
        }
    }

    time.Sleep(2 * time.Second)
}

func main() {
    someFunc()
    time.Sleep(20 * time.Second)
}

It surprised me a little other goroutines which still aren't finished don't cause panic because channel is gone even. For more realistic test I've also added some work after someFunc is finished.

Don't know why, it sure has to do with the way garbage collection works in Go (would be a great read if there's detailed explanation of it). I'm glad though I don't have to deal with goroutines panicking myself.

One thing I didn't do in example is cancelling the work running goroutines are still doing so they stop wasting additional memory. One idiomatic way to do that is with the use of context package from standard library, which provides cancellation and timeout mechanisms.

Auto-reloading (safe-write) issues of application development servers

Leave a reply

I have discovered new module bundler for developing applications in JavaScript. It’s called Parcel.js and my initial impressions are positive. That’s what I tweeted about it:

Parcel is a web application bundler, differentiated by its developer experience. It offers blazing fast performance utilizing multicore processing, and requires zero configuration. Basically a fast Webpack alternative only without tons of configuration. Read more about its features here. I discovered it while looking at some library’s package.json checking which dependencies it uses. I use this technique often whatever the language library is written in because that’s how I find new and exciting libraries which makes me more productive.

The first problem I encountered while using it, has actually nothing to do with Parcel.js itself, but the way most editors save files which makes Parcel.js’ and many other development servers’ reloading capabilities limited to only first file save. This feature is called safe-write which doesn’t save changes in original file, but in a temporary file. Temporary file is than renamed and replaces original. This causes development servers with reload capabilities to lose track of file. Luckily we can turn this off (how-to for popular code editors). But before you do this, please educate yourself about the advantages of using safe-write. To sum up, it guards you against data loss if editor crashes. In my case this almost never happens so I don’t see the point of having safe-write enabled.