RFC: remove components using in 2017 package only from component library?

[jaronheard]

This is something that had come up in conversation with @DingoEatingFuzz - removing some of the components that we didn't use in 2018 from the component-library.

This would serve a few purposes:

• Reduce complexity for onboarding new developers
• Reduce component-library dependencies and size (leaflet, I'm looking at you)
• Reduce complexity for Configure @hackoregon/component-library for use in other contexts #398

That said - it's not all upside, as we would have to do something about the 2017 package. Here are the options that I thought of:

• Pin component-library dependency for 2017 package to a version
• Create a new component-library-legacy package with the components and dependencies needed for the 2017 package.

Anyone have thoughts or ideas on how best to do this?

[DingoEatingFuzz]

Pin component-library dependency for 2017 package to a version

This seems sketchy just based on the nature of yarn workspaces. I'm not sure how well it would work if different packages in the workspace depended on different versions of a third package in the same workspace. Maybe it's fine, but I've personally never experimented with it.

Create a new component-library-legacy package with the components and dependencies needed for the 2017 package.

This is probably the fastest safe solution though I don't like it.

My personal preferred solution would be to migrate the 2017 packages to use the newer components. I don't have a good idea of how much work that would entail, but I don't like accepting the 2017 projects as "legacy".

[mikethecanuck-cb]

I’m sketched out by effectively placing the 2017 packages in amber too, which is how it’d feel to pin them to a legacy version of component library, and less so but still some to forking the library.

The right answer IS to update the 2017 packages, but I must admit the amount of spontaneous dev on anything in the past two seasons has been very sparse and only heroically conquered by one or two people. Are those people (clears throat, looks around the room) signing up for that?

[jaronheard]

My personal preferred solution would be to migrate the 2017 packages to use the newer components. I don't have a good idea of how much work that would entail, but I don't like accepting the 2017 projects as "legacy".

This would be my personal preferred approach as well, actually. In addition to the awesome feel-good of accomplishing this, I think there would be learning and benefits from doing this migration.

I did a quick review of the 2017 projects just to assess how complex this might be. Here are my notes:

Emergency response:

• The "Who Does Portland Fire and Rescue Serve" map could be a little tricky to adapt, mostly because the design patterns for displaying lots of information together with a map aren't really developed.
• Otherwise migration appears pretty straightforward

Budget:

• Needs a data visualization redesign to fit within new data visualization standards and components. This may be the most complex

Housing:

• Map Your Affordability is quite complex (and appears to be broken at the moment)
• The rest of the components appear to be straightforward to migrate, though there are definitely some graphs that are just images

Homelessness:

• Appears to be a straightforward migration

Transportation:

• I'm unclear on the functionality of the "Road Works Explorer", but that could be another tricky adaptation.
• The rest looks pretty straightforward, but would recommend some data visualization redesign (chart types and labelling)

The right answer IS to update the 2017 packages, but I must admit the amount of spontaneous dev on anything in the past two seasons has been very sparse and only heroically conquered by one or two people. Are those people (clears throat, looks around the room) signing up for that?

In the past, our projects haven't optimized for spontaneous development between seasons - once the flywheel of a Hack Oregon season is in motion - there is much more momentum, and I think to accomplish this project we would need some momentum. I'm unsure whether this would be a good or terrible on-boarding project for a new front-end team - I could see it going both ways.

[MikeTheCanuck]

In the past, our projects haven't optimized for spontaneous development between seasons - once the flywheel of a Hack Oregon season is in motion - there is much more momentum, and I think to accomplish this project we would need some momentum. I'm unsure whether this would be a good or terrible on-boarding project for a new front-end team - I could see it going both ways.

There's one way in which this could be a significant help to new teams: they'd have some real-live (not terribly-aged) React code to get familiar with immediately. When I'm not familiar with (or gotten rusty at) a language or framework, diving into mostly-working code and fixing issues is far easier than starting from a blank slate or a toy sample. I am totally guessing but I wonder if some UI developers in the past couple of years have found the React learning curve steeper than they'd like, or felt too idle while the designs and APIs were getting spun up. Maybe I'm optimistic that anyone would enjoy debugging someone else's not-well-documented code - however, as some possible training wheels while the projects get ready to feed UI developers, this seems like a decent playground.

Aside: while it's not immediately apparent, the Budget project is fairly broken too (e.g. date slider, bureau/service area drop downs don't cause the expected refresh of data).

[jaronheard]

We ended up upgrading all of these components in #423!