State of CSS TODO about stateofjs-legacy HOT 13 OPEN

Misc questions/issues:

• why is labelTextColor set on ResponsiveBar props instead of coming from theme?
• why is font family specified in theme?
• should years of experience, company size, etc. all be refactored into the same component instead of all having separate files?
• refactor SalaryPerCountryMapChart and ParticipationByCountryMapChart into same component?

from stateofjs-legacy.

• labelTextColor can inherit from bar color, theme or be a static color, that's why.
• font family is defined in theme because canvas doesn't care about stylesheets :)
• Maps could use the new @nivo/geo package's Choropleth component

from stateofjs-legacy.

Refactoring years of experience, company size, … means using an abstract bar component, I'm not sure it's required as nivo already provides the abstraction.

from stateofjs-legacy.

Regarding labelTextColor, please have a look at this guide (Single color property)

from stateofjs-legacy.

Regarding refactoring, I think the biggest thing we're missing is some kind of generic block and component for things like bar charts. Looking at DemographicsSalaryBlock for example, I don't see why it needs to have its own component?

And then same thing with DemographicsVerticalBarChart, it could just be a generic VerticalBarChart?

from stateofjs-legacy.

• Where do we get the tools descriptions (block.sass.description) from? If it's not automated, we might as well remove them?
• Browsers/Form Factors/resources/etc.: can we combine main options with "other" option in a single chart?

from stateofjs-legacy.

• Is it useful to specify blocks in the raw sitemap for pages like Demographics since we also list them out in the component itself? Isn't that redundant?

from stateofjs-legacy.

• We need to harmonize names between the sitemap and data. For example the sitemap uses company-size but the data has company_size

from stateofjs-legacy.

Yes, because we wanted to use company-size for urls, but it's not valid in elasticsearch

from stateofjs-legacy.

• It's also a little inconvenient that the data isn't always nested under the same property name. For example salary data is at salary.ranges but source data is at sources.by_source.

from stateofjs-legacy.

• Another related issue: do we want to compute just the data relevant to a single block first and then pass that to the block; or else pass the entire page's data to the block and let it extract the relevant data? Currently we're doing approach #2 but it feels a little messier maybe…?

from stateofjs-legacy.

We could use the same terminology as elasticsearch which use the buckets property, but I liked to have more meaningful names :) It might be easier when consuming the data for a single chart, but when manipulating it, it's really unpractical

from stateofjs-legacy.

I prefer the first approach, isolating the block's data, unless we have blocks which depends on each other

from stateofjs-legacy.