Category Archives: Web development

On MobX Redux dilemma

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.

New React Context API

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).

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

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.

Avtomatska rokometna lestvica (WordPress plugin)

Last weekend I developed for an acquintance a WordPress plugin which I’ve titled “Avtomatska rokometna lestvica” (translates to “Automatic handball league table” from Slovene). He’s a contributor to an official website of RK Trimo Trebnje, my local handball club and asked me if it’s possible to have a functionality which replaces the manual work of reading a website with statistics for a league table, selecting only a handful of columns and saving it to a blogpost. I had a lot of experiences with web scraping so I was immediately sure it can be done.

Without knowing where the scraped data will be displayed, I coded plugin’s option page using WordPress’s Settings API (and utilizing my library which simplifies creating option’s page). It’s just a textarea which accepts CSV-like data where each league table is represented in one line and one line contains a selection name and URL to its stats.

I have also coded a logic which actually scrapes the necessary data – table of team position, team name and team points and makes new table which is than saved into the database. For reading and constructing HTML tables I’ve used PHP’s DOMDocument. I’ve enjoyed working with this class.

Web-scraping is done periodically at midnight using wp-cron. They way wp-cron works is it launches when first user visits the site after the time it’s set to repeat.

Now comes the part where I learned how it’s going to be displayed. More than one league table needed to be shown (for selections like members, cadets, juniors,…), they were grouped in tabs. Inputs where they are edited were present on certain WordPress page using cusom fields. The problem for me was I had no idea where this fields are stored in the database. So the content from web-scraping process can be saved there.

I fixed this problem quite elegantly, I must say. I saved the content into wp_options table under a key {$package}_{$selection} and for displaying it I’ve coded a shortcode which queries wp_options for the key {$package}_{$selection} and returns HTML stored under that key – selection is specified as an argument to shortcode.

One-liner for serving static files in Go explained

Whenever I want to set up a server for serving static files in Go, which is not often, I always have to spend some time to figure out the following one-liner.

http.Handle("/images/", http.StripPrefix("/images/", http.FileServer(http.Dir("./images"))))

What confuses me probably the most here is all three strings being practically the same.

So in this post I will explain what this does for my future-self so he won’t have to google about it and will have it explained here in a way he’ll like it. 🙂

For this particular example (where one-liner above applies) let’s say we are storing images in ./images folder on a server and accessing them from outside of the server with <server's domain>/images/article2.jpeg

  • We shouldn’t set up a file server at root endpoint if our server accepts other endpoints.
  • http.FileServer(http.Dir("./images"))) exposes folder ./images as a handler.
  • http.StripPrefix is used because images are stored in ./images` folder and not in it’s subfolder images (we want ./images/article2.jpeg not ./images/images/article2.jpeg). It strips prefix from request’s URL.

A friendly reminder

Serving static files is more efficient using dedicated web server (Nginx, Apache,..). This approach also aids to better security of your application.