Verify Topcoder-app dependencies and update repository

[vic-georgiev]

We have quite a lot of dependencies https://github.com/appirio-tech/connect-app/network/dependencies and I'm not sure if we don't have duplicates or unnecessary small ones that we can remove and optimize.

The goal is to improve the infrastructure for connect-app so we have less dependencies and compile the app to a smaller bundle size.

1. Let's use tools like https://github.com/webpack-contrib/webpack-bundle-analyzer to track what duplicates we have, eliminate mass library include (lodash locales can be safely removed), and trim down the size of the package in overall.

2. Update the packages to the latest stable versions without breaking the CI/CD deployment/builds.

Sources:

• https://medium.lucaskatayama.com/reducing-bundle-js-size-from-webpack-8a9c3adbdad4
• https://reactjs.org/docs/optimizing-performance.html#webpack
• https://hackernoon.com/reduce-webpack-bundle-size-for-production-880bb6b2c72f
• https://hackernoon.com/optimising-your-application-bundle-size-with-webpack-e85b00bab579
• https://medium.com/@arturarsalanov/webpack-optimizing-your-bundle-size-ab0c90b1bf03
  to name a few, may not be the best sources.

[maxceem]

Done with the first part - reducing size. Gzipped size reduced from 724,96kb to 596,29kb, so file became 18% smaller.

Also, there are two more things which can be done to reduce size until
~546,14kb so it will 25% smaller in total.

1. Implement custom templates for notification messages instead of using handlebars
   So far for rendering notification we use handlebars templates which is very useful during development of notifications as we can output data in any way without writing our own template engine. Though the size of handlebars is pretty big 21,9kb gzipped. So if there is no plan of planty of changes in notifications, we can write own template engine with only necessary functionality. Probably it will be much smaller.
2. Reimplement SliderRadioGroup from appirio-tech-react-components without rc-slider.
   Currently to display SliderRadioGroup which looks like this http://take.ms/r6ep2 we use rc-slider which has quite a plenty of dependencies including rc-tooltip, which requires rc-popper and dom-align. In total 24,26kb gzipped. But in reality rendered component is very simple, it's more about CSS styles.

As these two thing can be separate tasks and could be somehow time-consuming, let me know if you want to accomplish them during this task, make separate or postpone them for now.

Done	gzipped size (kb)	reduced size (kb)	reduced size (%)
Initial size without polifills	724,96
ignore moment .locale files	677,43	47,53	6,56%
import per method from appitio-tech-react-components	616,01	61,42	8,47%
added babel-plugin-lodash, to import per method from lodash	600,54	15,47	2,13%
updated to recompose@0.26.0 which has to support tree shaking	598,7	1,84	0,25%
removed unused isomorphic-fetch	596,29	2,41	0,33%
removed redux-logger from production build	592,3	3,99	0,55%
Total	596,29	132,66	18,30%

Two more things which can be done.

Can be done	gzipped size (kb)	reduced size (kb)	reduced size (%)
implement custom templates for notification messages instead of using handlebars	570,4	21,9	3,02%
reimplement SliderRadioGroup from appirio-tech-react-components without rc-slider	546,14	24,26	3,35%
Total can be reduced	546,14	178,82	24,67%

[vic-georgiev]

For 1 - I have no opinion.
For 2 - let's get the component refactored in such a way that it would be a candidate for the new react-utils repo

@maxceem did you check on importing only the core of Lodash? All the locales can be removed safely. This was a big potential file size saving. Another one was the missing vendor and common chunks plugin, as we had a lot of the same dependencies in the modules?

new webpack.optimize.CommonsChunkPlugin({
  children: true, 
  minChunks: 6
})

from https://medium.com/webpack/webpack-bits-getting-the-most-out-of-the-commonschunkplugin-ab389e5f318

In my investigations I saw Immutable being there several times, and the loads locales

What is the value of rebuilding the notification templates from handlebars int react? Is this going to remove the dependency on handlebars package? Would this make it harder to maintain notifications in the future? @gondzo @vikasrohit @RishiRajSahu @mtwomey FYI

[maxceem]

@vic-topcoder yes, I've excluded moment locale files from the build. And I use babel-plugin-lodash plugin which makes webpack include only that lodash functions which are being used in the code.

So currently bundle looks like this. There are no code duplicates now so we can skip usingCommonsChunkPlugin.

What is the value of rebuilding the notification templates from handlebars int react?

The thing was that notifications were developed and changed quite fast. Requirements were changing. So instead of creating multiple versions of notifications, I used handlebars to render output of notifications which could have various input parameters. Using handlebars let us easily change render of notifications for new requirements. Also, handlebars let us define notification message templates in a quite easy way and developers are familiar with the syntax.

Is this going to remove the dependency on handlebars package?

Yes. Handlebars are being used for rendering notifications only.

Would this make it harder to maintain notifications in the future?

Depend on the new requirements. So far handlebars let us control rendering very flexible. Custom render function has to be more specific so new requirements could lead to changes which have to be done to custom render function. In the worst case we may end up reimplementing handlebars, though I think it will hardly happen.

[vic-georgiev]

What I would like to do is to think about the notification templates as DB records. I imagine we can keep a version of the notification template in a DB and have placeholders for the unique data. This would allow us to further think about internalization (i18) when we want to allow an interface to be in other language than English.

This means that the front-end won't be generating the notifications, but just render them through the API response. Would this affect the need for Handlebars?

For the time being I think we can safely leave handlebars as is, but I want us to think about what's next.

FYI @vikasrohit @mtwomey

[maxceem]

Currently, we have versions implemented for notifications.
Templates are being kept in connect-app and they also have versions.
Basically, we may add i18 for templates inside connect-app if these templates are only needed for connect-app. Or we can download from the DB. Anyway we already have notification templates with versions which we can store in any place.

So far we use Handlebars to render bundled notifications like this:
"vikasrohit, mtwomey, gondzo +123 more created 45 new posts to your topic"
template for such messge looks like this

{{#showMore __history__ 3}}<strong>{{userHandle}}</strong>{{/showMore}} created {{bundledCount}} new posts to your topic

Also, because we may have different versions of notifications in one bundle and that notifications may have a different set of data, Handlebars let us easily handle such cases using fallback.
For example new notification have userFullName but old one have only userHandle, so template looks like this:

{{#showMore __history__ 3}}<strong>{{fallback userFullName userHandle}}</strong>{{/showMore}} created {{bundledCount}} new posts to your topic

If we avoid using Handlebars, we have to write our own template engine to support such cases. And now after revising notification rendering one more time, I would suggest keeping Handlebars for now. As writing own engine will take time and in the future, we may end up reimplementing Handlebars. Maybe we can come back to this when requirements for notifications are settled down.

[gondzo]

agreed. works ok for now and 20kb isn't such a big deal for the convenience we get with these templates

[vic-georgiev]

I don't mind keeping handlebars. It is small price to pay. We can optimize much more from the list of components we use, and data we transmit. Let's call this one done if we have the optimizations in DEV

[maxceem]

I still haven't made this

Update the packages to the latest stable versions without breaking the CI/CD deployment/builds.

Though maybe it makes sense to treat it as another task and do it together with #1564.
There is a big chance that updating some of packages will require React 16.

And this

Reimplement SliderRadioGroup from appirio-tech-react-components without rc-slider.
Currently to display SliderRadioGroup which looks like this http://take.ms/r6ep2 we use rc-slider which has quite a plenty of dependencies including rc-tooltip, which requires rc-popper and dom-align. In total 24,26kb gzipped. But in reality rendered component is very simple, it's more about CSS styles.

Should it be another task or do it here?

[gondzo]

We can leave those for a different task and do it after upgrading to React 16.