![]() Component (15) shouldn’t heavily take advantage of dependency injection and should “generally” take what it gets from the outside world and send it back out. Which component in this tree should be the smartest, (1) or (15)? I would hope (1). This helps us all fall into the pit of success and avoid troublesome software maintenance issues due to complicated logic deep in the component tree. So if you advocate for DRY, then in reality, Component Tree 2 is more desirable even at the expense of a few extra keystrokes and repeating yourself at the top level of the tree.Įmber enables flatter component trees with block syntax and a variety of other initiatives. Actions, data, and stylistic concerns get buried deep into a component tree, making it hard to reason about what this page is supposed to do. As the app becomes more complicated, the API of the components inevitably expands with complexity. Component Tree 2 only has one child component we need to deal with. ![]() Probably the second one (although edge cases are abundant). Which tree structure would you prefer assuming each underline ( _) is a component and it flows from top to bottom? So how can we design components that are built for the long term and are understandable in parts? 1. We also want the ability to refactor without breaking a sweat that your whole application will break. We need the ability to understand each piece of the app clearly and successfully. On a large app, this becomes even more important since there is no way any of us will understand all parts completely. It’s not about making changes in one place. What we are really talking about is our ability to read and understand the code. I have always been confused by this term, which was eloquently described by Ed Faulkner in this tweet. Let’s prime this conversation by talking about DRY. However, I feel one topic that, as a company and a community, we don’t talk about nearly enough is component design. Apart from his ability to write clear and concise code, learning about fast properties has been insightful and has made each ingredient in our system discernable and self-evident. In addition, Sergio Arbeo is a force within DockYard. ![]() As a result of learnings from Brian Cardarella, I’ve greatly enjoyed maintaining tests suites while at DockYard. Abstractions in tests can be difficult to refactor over the long term. Many parts of our applications are prone to logarithmic difficulty. Without a team understanding of the tradeoffs that exist with wep app development projects, we may be a danger to the system we are trying to develop. Understanding a large system requires multiple mental models and a latticework of knowledge. Similar to the old adage of just wanting a banana, but instead, you got a gorilla holding the banana and the entire forest, the same applies to components and how you design your component dependency tree. But components, just like classes, can be abused. Of course I don’t believe components are bad. Framework Components are terrible abstractions and experts are fallible. ![]()
0 Comments
Leave a Reply. |