Replies: 2 comments
-
Super happy to hear that 🎉 |
Beta Was this translation helpful? Give feedback.
0 replies
-
I am in full support of this change. It personally took me months to understand how things were put together in our codebase, and even today as the complexity grows I get stuck on FX issues. It makes our code very uninviting and unapproachable. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I propose removing the use of Uber-FX from our NodeBuilder implementation in favor of a straightforward constructor approach. Currently, the NodeBuilder relies heavily on Uber-FX, which utilizes reflection to wire up dependencies. This approach introduces a level of complexity that obscures the internal operations of the application, making the codebase difficult to understand and modify.
The existing NodeBuilder configuration with Uber-FX is not only complex but also imposes a significant cognitive load. As a result, comprehending the application's dependency graph is becoming increasingly challenging, pushing us towards a situation where the codebase may soon be considered a legacy burden.
Here are the key functionalities we expect from NodeBuilder:
By transitioning to plain constructors, we can maintain these functionalities but in a more explicit and manageable manner. This shift will involve encapsulating all necessary dependencies within a single 'superStruct' of Node. Such a structure will greatly simplify the code while preserving the visibility and modifiability of the dependencies, which is crucial for readability and maintainability.
I believe this change will streamline our development process and enhance our ability to maintain and evolve our codebase effectively.
Beta Was this translation helpful? Give feedback.
All reactions