setup topcoder-react-utils as a dependency of Connect App, and adopt Babel configs from there

[vic-georgiev]

Let's figure out how to add topcoder-react-utils into Connect and start the unification process for our apps.

From @birdofpreyru #1442 :

Tt would be ideal to already try to setup topcoder-react-utils as a dependency of Connect App, and adopt Babel configs from there in Connect App (it might demand some work, cause those configs use Babel plugins to support CSS modules, thus any CSS code written before without CSS modules in mind should be wrapped into :global blocks, to keep it working).

@vikasrohit @gondzo @RishiRajSahu @maxceem @ThomasKranitsas @mtwomey FYI

How different is the environment and what would it take to do the step?

As a refactoring effort - can we also substitute our button implementations with the button component used in community app? We would need to document the process for the steps, so any challenge work should include a detailed user documentation. Also - I like how the code on community app is very well documented, can we try to get to a similar level of documentation in Connect?

Thanks!

[birdofpreyru]

For the button, I am still working on spawning this out of Community App. The JSX <Button> component itself is already moved to topcoder-react-utils, but moving related TC UI Kit to a separate repo, and also properly packing it for re-use in other apps, it will take me some more time.

[vic-georgiev]

Sounds like a great progress!

[vic-georgiev]

I also was playing with some react ui component libraries to see if we can grab and reuse any components from there for our needs.

Have you had any experience with Element http://element.eleme.io/#/en-US/component/button (they have a react port https://github.com/eleme/element-react/tree/master/src) or Ant Design https://ant.design/components/timeline/

[birdofpreyru]

C'mon @vic-topcoder , we are Topcoder community, we can create any components from scratch ourselves :)

We do use some 3-rd party components though to save time :)

I see you link specifically to the <Button> in Element? I believe, it is somewhat technically different from the <Button> we use in Community App. Our <Button>, under-the-hood, is a hybrid of <Link> (which in turns can be a simple <a> or React Router's <Link>) and <button>. The way it, and its themes, are done ensures that once it is correctly laid out into the page and styled, if one day you come to me and say: this button should redirect user to another page inside the app; and the next day you say let's replace the redirection by some logic, and yet another day let's redirect user elsewhere and do some API call before the transition; our <Button> allows to make such changes very easy, and without any care about its styling.

[vic-georgiev]

I am sure we can build everything :) Just want to look at what other people are doing and get the knowledge from libraries transferred to our library. The goal is not to reinvent the wheel and if there's a good component candidate we'd get the code. I hate code bloat and building a library of all different generic components is not great.

The button in Element has interesting properties we haven't designed/used - loading status of button, icons in button, segmented button.

I like the versatility of the button we have now, don't get me wrong :) Not suggesting we replace it at all!

Third-party components that we heavily use:

• React-select
  ... not sure if we have others

[birdofpreyru]

Without looking into the code, I recall that we also use react-stickynode, something for tooltips, react-waypoint, something for date/time selection; I guess something else.

[vic-georgiev]

@maxceem is going to add a utility - react-popper which wraps popper.js and now reimplementing Tooltip - for positioning of elements - tooltips, dropdowns - and this could potentially replace react-stickynode as the aforementioned library supports auto viewport detection and affix.

Do you think we need a new discussion thread on the components and start mapping all that we are going to replace? I don't want to be building new components in isolation for only one product, but share between all, so we can check use cases in advance and not rebuild the same components 3-4 times.

[maxceem]

How different is the environment and what would it take to do the step?

Regarding topcoder-react-util environments are almost same.

• The biggest difference is CSS Modules which connect-app doesn't use, but community-app does. So as birdofpreyru said we will have to add :global to all existent CSS files in connect-app in order to works with CSS Modules
  UPDATE
  Just remembered. As communit-app uses babel-plugin-css-modules-transform which is lightweight version of react-css-modules and doesn't cover all use cases. In theory there could be some other cases which will require additionaly adjustements. I don't remember what are restrictions of babel-plugin-css-modules-transform in comparison with react-css-modules.
• Second thing is that connect-app requires coffeescript (which is required by its dependencies). And also there are other cases when custom modifications have to be applied to webpack config. For example, connect-app uses handlebars for rendering notifications. Handlebars has an issue which is fixed by adding

  alias: {
    handlebars: 'handlebars/dist/handlebars.min.js'
  }
  

  Thus, probably topcoder-react-util has to support custom modifications which can be merged to default webpack configs. Previous package which played role of topcoder-react-util https://github.com/appirio-tech/webpack-config does support customization of webpack config if I'm not mistaken.

[birdofpreyru]

Thus, probably topcoder-react-util has to support custom modifications

Sure, it does. For the Babel configs we are discussing now, they are done there as presets, and a Babel preset is just a JS object, holding lists of presets and plugins to use, their options and order. So, you can just import a preset provided by topcoder-react-utils, mutate it the way you need, and inject as your customized preset into Connect App's Babel config. However, this opportunity should not hide the fact that we want to eventually just reuse the very same config, so we need to gradually refactor Connect App for that (getting rid of Coffee Script dependencies, moving to CSS modules, etc.)

Just remembered. As communit-app uses babel-plugin-css-modules-transform which is lightweight version of react-css-modules and doesn't cover all use cases. In theory there could be some other cases which will require additionaly adjustements. I don't remember what are restrictions of babel-plugin-css-modules-transform in comparison with react-css-modules.

Me neither, so I believe, in 95% cases it is nothing to worry about. The main difference is that babel-plugin-css-modules-transform makes all necessary class name substitutions at the compile time, rather that on the run time; but, I believe, when something cannot be resolved at the compile time, it still injects some helper functions that do the runtime resolution, so I don't know, what are practical restrictions, if any at all.

[birdofpreyru]

For the Webpack config, I am in progress of moving the standard part of it from Community App to topcoder-react-utils. It will sure demand some customization for each project using it, and it will be easy to do, thanks to webpackMerge(..)

[vic-georgiev]

Sounds great you guys! Let's keep pushing and plan the modifications done in Connect. @gondzo - do we need a new issue for all that's needed to include topcoder-react-utils?

[maxceem]

@gondzo currently to fix installed dependencies tree we use npm-shrinkwrap.json file. Can we remove it and use package-lock.json which is handled my npm@5 automatically? So we don't need to take care about it manually like it's described in readme.

[gondzo]

yes, I think that's a good idea. we introduced shrinkwrap so we could have reproducible builds. package-lock serves the same purpose so we should be fine.