Posts

Multiple React bundles on a single server Express server (Part-2)

This is the second part of "Multiple React bundles on a single Express server". If you haven't read the first part yet, please go to Multiple React bundles on a single Express server (part 1) . Setup the first React App After setting up the hosting server, we are ready to set up the first React App. In this setup, we are going to use React, Redux, Babel, and Webpack, etc NPM packages. Due to this sharing might become obsolete after tomorrow, we are going to specify the intended version when installing the NPM packages to avoid the problem of having the trouble in following the example. Webpack and shared folder Let us begin by configuring the Webpack and put the sharable code in place. 1. While in the root of the project folder, type following commands at the terminal: npm i react@16.8.3 react-dom@16.8.3 npm i react-redux@6.0.1 redux@4.0.1 redux-thunk@2.3.0 npm i -D babel-core@6.26.3 babel-loader@7.1.5 npm i -D babel-preset-env@1.7.0 babel-preset-react@6.24.1

Multiple React bundles on a single Express server (Part-1)

This is the sharing about setting up multiple React Apps to be hosted by a single Express server. Most of the web projects do not require this kind of setup. In common practice, an Express server usually just hosts one React App. This should be the way to go most of the time. ------------------------------------------------------------------------ | | | ------------- ------------------ | | | React App | <------------> | Express server | | | ------------- ------------------ | | | ------------------------------------------------------------------------ In my current project, there is a need to have separate React Apps to be hosted by a single Express server. This is to allow control on user access while using a single Docker container. -------------

Setting Up Syntax Highlighter In Blogger (Part-2)

In the previous post, I wrote part one of Setting Up Syntax Highlighter In Blogger . I like the font, the auto line number and the colour on the coding syntax. But there is one problem with the setup. The syntax highlighter seems outdated, not really highlighting latest programming syntax (eg. 'const' in ES6 Javascript) I went to check around if there is another way, and I found one. After finishing setting up, this is the result: const array1 = [1, 2, 3, 4]; const reducer = (accumulator, currentValue) => accumulator + currentValue; // 1 + 2 + 3 + 4 console.log(array1.reduce(reducer)); // expected output: 10 // 5 + 1 + 2 + 3 + 4 console.log(array1.reduce(reducer, 5)); // expected output: 15 var array1 = ['a', 'b', 'c']; array1.forEach(function(element) { console.log(element); }); // expected output: "a" // expected output: "b" // expected output: "c" If the syntax highlighting colour look familiar t

Setting Up Syntax Highlighter In Blogger (Part-1)

Today, I tried to find a way to do syntax highlighting to the code sample in my blog post. Using my custom CSS, this is what happened before I embedded the syntax highlighter. const array1 = [1, 2, 3, 4]; const reducer = (accumulator, currentValue) => accumulator + currentValue; // 1 + 2 + 3 + 4 console.log(array1.reduce(reducer)); // expected output: 10 // 5 + 1 + 2 + 3 + 4 console.log(array1.reduce(reducer, 5)); // expected output: 15 var array1 = ['a', 'b', 'c']; array1.forEach(function(element) { console.log(element); }); // expected output: "a" // expected output: "b" // expected output: "c" This is what happened after I embedded the syntax highlighter. const array1 = [1, 2, 3, 4]; const reducer = (accumulator, currentValue) => accumulator + currentValue; // 1 + 2 + 3 + 4 console.log(array1.reduce(reducer)); // expected output: 10 // 5 + 1 + 2 + 3 + 4 console.log(array1.reduce(reducer, 5)); // expected ou

100% Test Coverage?

When you write unit tests, do you try to achieve 100% test coverage or are you content with anything above 80% test coverage? Most of the time, I feel that trying to achieve 100% test coverage is a waste of time. The return of investment starts to diminish once the coverage goes above 80%. However, what happens today make me reconsider the benefits of trying to achieve 100% test coverage. This was the original code: 10 function isFullyCheckedBy (type, data) { 11 const { entries = [] } = data 12 13 for (const entry of entries) { 14 const { results = {} } = entry 15 if (results[type] !== true) { 16 return false 17 } 18 } 19 return true 20 } 21 The coverage tool complained that "line 11" was not covered. My initial reaction was, "does it matter?". Anyhow, I tried to write a test to create a scenario to trigger the default assignment in "line 11". After running the new test, I was surprised to find out that "isFullyCheckedB