Current Behavior of the ComponentCurrently, to use this component, we just insert its container in the markup of a community page, as <CommunityStats />, e.g. check the Home page of demo-expert community. This container takes data from state.stats.communities[communityId] section of the Redux state. And for each key found in that object, it renders an icon, the value from the state, and the title of the parameter. The icon and title to use for each statistics key are determined based on the mapping hard-coded into the CommunityStats component.
Optionally, a stats prop can be passed into CommunityStats container. If provided, it will be used instead of the data from Redux store. Its purpose is to be able to easily hard-code specific stats values for demo purposes. As example, check the taskforce community's Home page.
ProblemThe current implementation of the component/container turns out to be not flexible enough for our needs. For example, check the style of community stats block in the wipro (TopGear) community. While the stats themselves are the same as for other communities (i.e. they are based on the same keys/values in the corresponding section of Redux store), the style of rendered block is completely different: different icons are used for stats parameters, and the styling of text / layout is also different. To rapidly implement this for wipro community we had to clone and customize CommunityStats component / container. Now we want to refactor original component to ensure that it is flexible enough to use in such scenarios.
Requirements- The default behavior and style of CommunityStats component / container should stay the same as now (including hard-coded default mapping between statistics key and icon / title);
- Ensure that if stats data object contains a key not present in those default mappings, the code does not break (just don't render icon / title for such stats parameter);
- Convert the component / container to use react-css-themr for styling (i.e. the theme can be passed as theme prop into container, which will pass it into component, thus providing the user a way to completely customize its look);
- Allow to pass into container icons and titles props, which will override the default mapping between keys and icon / titles. When we render a stats with specific key, if such props are provided, we will first look for iconst / titles to use in these prop object, if they are not there, we fallback to defaults;
- Allow to pass into container filter prop. If provided, the component should render only those stats, which keys are also present in filter object (and have truly values there);
- Update wipro community to use refactored component, and remove the customized one it is using now.