Skip to content

Potential Issues

Jump to bottom
Jake Polatty edited this page Aug 13, 2018 · 3 revisions

The Goal

The optimal use of this library is going to be in sharing very generalized components between similar looking and similarly functioning front-end projects. A good example of this is the table view component. It is a component that does one thing well: translate a json object to a table view with several different input types. Because it is fairly stable and generalized to handle many types of inputs, it is a good fit for the component library. Getting more components to this state will maximize the usefulness of this library.

The Issues

  • One particular component that should be optimized to be used in the component library, but very much is not is the FlowFooter. It is not standard across the different projects and it is not the dumb component that it should be. I would love to see it in the react-component-lib, but honestly its a tightly coupled mess that I (Ryan) am mostly responsible for. In some projects it actually does requests to save data or check that the user is logged in, in others it gets that data in props as it should.

  • The react component library does not export any container components, because many of them are too tightly coupled to outside libraries that we do not want in the component library. This is something that should change in the future.

  • Don't use react-tap-event-plugin it is not required for material ui anymore use react >= 16

  • In package.json this: ["package": "^2.1"] does not mean any version over 2.1 it means any version >=2.1 and < 3.0 this can be super frustrating, if you mean any version over 2.1 use ["package": ">=2.1"]

  • In the wms project (and I suspect others), when trying to develop using a local copy of the react-component-library, this error can sometimes show up: "Element ref was specified as a string (myRefName) but no owner was set...You have multiple (conflicting) copies of React loaded (eg. due to a misconfigured npm dependency)" the problem here is in fact that there are multiple copies of react loaded. A hack to get around this is to delete react-component-library from node_modules in the wms project and delete the entire node_modules directory in the react-component-library and then npm install --save ../<whateverPathTo>/react-component-library. As far as I know The problem here is not that react-component-lib is misconfigured with npm, but that it has a node_modules folder that is initialized outside of the npm install from the wms project. Typically, when a package is installed with npm it has no node_modules.

  • The way we handle styling with react is somewhat broken. We approach it 2 ways right now, inline or (this is the prefered approach) import 'componentname.css'; The first approach is wrong because it is too tightly coupled and makes it too dificult to make changes to component appearence. The second is wrong because when you import a css file, it gets applied to all of the elements that are rendered. This can lead to collisions. Webpack has a solution to this that appends a unique id to the classnames and ids, but we haven't gone into it yet.

  • The Material UI framework, upon which most of our components are based, has moved active development to version 1.x and other libraries will likely end support for MUI v0.x in future versions. The extensive changes to Material UI in the v0 -> v1 migration will probably demand a full rewrite of all Material UI-based components, but this may be necessary to future-proof the component library.

Clone this wiki locally