<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>React on Personal Blog of Maximilian Ehlers</title><link>https://blog.sodawa.com/tags/react/</link><description>Recent content in React on Personal Blog of Maximilian Ehlers</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sun, 25 Feb 2018 18:56:00 +0000</lastBuildDate><atom:link href="https://blog.sodawa.com/tags/react/index.xml" rel="self" type="application/rss+xml"/><item><title>Testable modules</title><link>https://blog.sodawa.com/blog/testable_modules/</link><pubDate>Sun, 25 Feb 2018 18:56:00 +0000</pubDate><guid>https://blog.sodawa.com/blog/testable_modules/</guid><description>We should write our code in a Test Driven style. I agree. Yet I find myself working on small side projects quite frequently, where I just want to hack something and make it work.
Now, lets say I actually want to keep growing my codebase, but it is all untested
I could easily look at every file, mirror it into a test directory and then write my tests there, while switching between files constantly.</description></item><item><title>(react-) frontend perfomance monitoring</title><link>https://blog.sodawa.com/blog/react-frontend-perfomance-monitoring/</link><pubDate>Fri, 16 Feb 2018 17:14:00 +0000</pubDate><guid>https://blog.sodawa.com/blog/react-frontend-perfomance-monitoring/</guid><description>Frontend performance monitoring from scratch The first question you should ask yourself when thinking about Performance optimizations is the following:
Is my service unique enough to focus more on features and only do rudimentary performance optimizations, or do I rely on being the best in the business to attract costumers?
If you need to be the best because of generic features you should invest in the performance part, and here it is all about perceived performance.</description></item><item><title>Multi Tenant React.js starter</title><link>https://blog.sodawa.com/blog/multi-tenant-react-js-starter/</link><pubDate>Fri, 07 Jul 2017 18:53:00 +0000</pubDate><guid>https://blog.sodawa.com/blog/multi-tenant-react-js-starter/</guid><description>Let me start this article with the requirements that it is going to adress, so you know if you want to continue.
You have multiple tenants (websites) the clients should share components between each other to increase development speed of new tenants SSR has to be supported build configs are the same, but can be extended Since these are quite a few things and a lot of good stuff is already open source I am only going to focus on what needs to be added onto the great react-starter-kit.</description></item></channel></rss>