22 Jul 2016
Reading time ~2 minutes
What I Did
- Attended FBF
- Intern Meeting: User Research presented by Laura
- Spent the rest of my time on replacing Ben’s static content for “These Numbers Matter” with the dynamic content pulled in from the CK blocks that I’ve defined. All content is currently visible and styled on the homepage - though there is a bit more styling to be done and final touches to be made. Though I had to make a few changes to the components that I had built beforehand, most of the replacement process went surprisingly smoothly.
What I Learned
- UI programming is extremely hard, especially because there are many situations in which components are aesthetically very similar or the same yet completely different functionally. As one builds out an application, it’s easy to fall into the trap of overgeneralizing components for reuse. This is especially problematic in light of UX/Design updates. Thus, there is a fine balance between DRY and getting things done the accurately and precisely.
- A good rule of thumb for the above rule is to avoid doing too much state checking within components. This extends beyond React to CSS as well.
What I Still Don’t Understand
Though I’ve got most of the moving pieces working for “These Numbers Matter”, I am still very unsure how Viget generally integrates CK and React into their Ruby apps, because it seems like the sort of micro-managing of content on a single homepage that I’ve dedicated myself to for the past week is somewhat unrealistic and excessive for the typical production app that Viget puts out. In other words, I’d like to gain insight into what things generally end up being modeled as CK components on a typical site, because I’ve realized that modeling individual links as part of individual text sections on “These Numbers Matter” has been rather tedious and ironically inflexible.