Using Redux all over is an anti-pattern – why?

I am attending quite a few job interviews these day and we sometimes we discuss React and Redux.

I was presented with the idea of using Redux “all over”. To me that sounds like you have no attributes in your components and connect to redux in every component all over your solution.

This is not the way to go. Creating components that takes attributes is the core to Web Components. It is based on the mindset of all of the web and the work of WHATVG and html standard. It makes your component readable and reusable.

You don’t want to connect to Redux store in all of your components. Connect in the container and propagate to your components using props.

An example I discussed in an interview today was a todolist.

See code below…

EDIT: The pastebin is incomplete and one problem in the code is the iteration sequence – the number in row of todolistitems needs to be propagated in my anti-pattern.

The point is – any kind of component that takes data should receive them as attributes/properties. I was just introduced to the idea of using Redux “everywhere” in an interview and my point is that you do not have to connect every component to redux. This will even make your code slower (perhaps) – you iterate over the array and you do not access the values in the loop.

This is really sigletonitis all over again – as a disease where you over-use a pattern. Just on Redux or whatever datastore you might implement.

Lessons learned from developing and introducing the Smileyhash app

At http://smileyhash.perandersen.no you can see a React Web app I have developed myself. But no one uses it. However, at least, I know I am able to make a web app.

I have things on my Trello board that I will look into, unless I start chasing other ideas and I have stopped doing development as I uploaded it to the host and posted about it on LinkedIn, I posted it on Reddit and I posted it on my facebook profile and no one has made any tweets with the hash tag.

For me it is hard to know if it was the idea and concept that didn’t seem appealing to people (what is the use for the tweeter anyway? They don’t benefit from rating their tweet mood using my hashtag) or if I just have not been doing enough to gain mass interest. It is not something I would try to make viral through spending on ads, as I would not see any income from it. And working more on making it indexable for search engines is something I have on my list, but I do risk that people never tweet using the tag even if it is indexable for search engines. So it is hard not to move focus over at developing other apps and ideas.

If I was to make some kind of app and/or web service successful, I think it would have to be concerning something people actually need. And those ideas are hard to get. At least now I know that I have the ability of following thorugh and I know I am technically able to make a solution based on an idea. This is great news.

Upgrading websites with SPA behaviour without destroying search engine readability and design.

I started doing web frameworks a few years ago and have been experimenting both with Angular and React. What I normally think is that the Javascript application is what I design and nothing more. And normally it is designed as a single page app.

Basically what happends when you create an app in a JavaScript framework is that you let the framework take control over the DOM manipulation but it is known that search engines can’t see the content.

In react there is a way past this that is called isomorphic react and this is a good strategy if you are building a new interactive website today that is kind of unique when it comes to functionality. At least it is an option to using a CMS.

But if you already have a website, and you use a CMS that server side renders the content it can be upgraded making parts of it into React or Angular apps. You can even do this with existing parts of a website.

The interesting thing is in the way a single page app is mounted in to your website.

In a Single Page App you have a static html file that usually only contains a div element with a ID such as “root” or “app” and little other. And this is what google sees. An empty element. Everyting else happends in time after this has been loaded and Google doesn’t follow this. It only sees the empty div.

But the beauty is, as an alternative to isomorphic renderToString in react – the mount div does not have to be empty.

This means that the following approach can be taken, both when creating web sites from scratch instead of running node.js on the server, you can place static content in the div.

I think you will find benefits in isomorphic react and building with this as an architecture for web apps and services that exist online, but when upgrading existing sites, this is beautiful. Take the static content and introduce dynamic behaviour with the existing markup and style as base and mount to the div you would like to make into a dynamic application and perhaps if needed design some small services hosted elsewhere or in the scripting language available on the host of the website.

The web is upgradeable and static websites still are major online. They can be upgraded and this does not have to affect search engine readability. Your website can have the same existing design as before, but be extended into having the functionality it lacks without a big affect to the design that might have been carefully done with a colour theme, fonts, a layout etc.

My point on use of reactDOM.render() in SPA templates and scaffolders:

But the beauty of ReactDOM.render is that it sets innerHTML behind the scenes. It doesn’t add the React components to the div with the id “root”. It swaps the content. Therefore:

In this way you can make use of react in existing websites leaving the static content in the mount node so that Google and other engines can see some text. Great for use on upgrading existing websites.