This entire article is an example of the largest pain point when working with React. So much of the work done here simply can't be done without various hacks around `useEffect`, `useMemo`, or `useCallback` (manual memoization). I feel to this point that even with the new React beta docs explaining the use cases for `useEffect`, it still causes an immense amount of pain in some situations.
It's not immediately clear when writing code that uses `useEffect`, when it's a very bad idea long term for performance or code clarity. This often shows itself when the test data is very minimal and then the real data is far more expansive.
I still love React, but these complex scenarios definitely show some of the limitations in React's rendering model that other frameworks like Vue, Svelte, and SolidJS resolve.
Trunk based development, while fashionable today does have some theoretical downsides. Imagine a feature toggled code base in the limit - no actual functionality, just partially baked features behind toggles. The end result is a series of branches manifested in the code itself - with no actual "mainline" as nothing has ever been completed. I'm pretty sure that would not be awesome.
Of course, a branched code base in the limit is similarly never merged which obviously is terrible as well. My main point is don't follow trends, instead simply do what what makes sense - that might mean feature toggles, branches or some combination. Stay awake, be creative and avoid dogmatism: sometimes things are better out than in, other times better in than out.
A single code base with half-baked code under feature toggles seems different from "a series of branches manifested in the code itself". Branches would mean there can be different versions of the same half-baked feature that need to be reconciled.
Are you saying that people in this thought experiment would go so crazy with feature toggles that they'd develop several different versions of the same feature, each with different toggles?
Yes it's possible for feature branches to look a bit like feature flagged code, but other than that, the administrative and organizational implications seem very different.
The most obvious being, it's a lot easier to see everything when it's in one place.
The hypothetical is the code is half baked, never completed and obsolete. In TBD, work is required to remove it. If using a branch, nothing needs to be done.
I guess I would hope that some thought or review takes place prior to merging to the trunk, such that the work merged there is suitable to build on, not just everybody's unfiltered shower thoughts.
That, to me, is the difference between committing on a branch and merging back to trunk/main. A branch is just a way to record and share an idea. Merging back is saying with some confidence "this is something we should build on". Feature flags allow you to disentangle that social signal of "we should build on this" from "this works in production".
I'm not sure (and curious) about other ways of working that can fulfill the same collaborative social signaling function.
For that matter, what is the benefit of TBD for managers? It’s a development technique—specifically, a rebranding of continuous integration, because that name was coopted by tool vendors.
I think it’s quite a reasonable method. But there’s no one size fits all.
Advocates of methodology will often speak in absolute terms. Plus their way of doing thinks is sometimes presented as a big magical revelation. This article is actually not like that, it reads like a historical summary.
It’s of course good to sometimes think about other ways of doing things. But in the end the way you’re using version control should reflect your requirements and development practice and not the other way around.
We do 1 main branch plus tagging. That’s it. It’s simpler for us and it’s a motivator to write code that works _now_.
But if we ended up in feature flag hell we would probably reconsider or simply branch off. Just be pragmatic about it.
There are of course companies with predefined rules about these things. I can’t speak to that.
Does it help to add removal of feature flags to the definition of done of your epics? Then isn't it much the same as staying on top of any kind of tech debt?
So the problem is not the feature flags. If the code/system doesn't get improved bit by bit (is ok to have technical debt), then, whatever the technique, you are going to end in a bad place.
Isn't it only combinatorial explosion if you need to maintain and test all those permutations. But those feature flags have a default value that they get stuck at. So the real remaining problem is pretty much: dead code. Which, again, that's "just" a common type of technical debt.
But hey, I am not arguing for feature flags. No, Sir, please no.
> But hey, I am not arguing for feature flags. No, Sir, please no.
Why do you prefer not to work with feature flags? For context, the product I am working on (which is not very big) uses a simple development/production split to enable or disable features. Several people have recommended using feature flags, but since I have not previously worked on projects that utilized them, I want to learn more about the advantages and disadvantages from a developer's perspective.
I was arguing against the notion that it necessarily leads to a combinatorial explosion. But there is a definitive cost to using feature flags, which I believe can be weighed against other options. In the types of environments where I work, we are able to avoid spending this cost most of the time, without major drawbacks. I'd say, the rare feature flags we have are very short-lived and mostly in the frontend (spa), very rarely in the backend, probably due to a decent team discipline around backward compatibility.
not allowed to integrate with other people's work in progress without a trip through main. also dont know how you are supposed to put out maintenance releases.
You can follow the core of trunk based and still work together with another person on a shared feature branch if that is needed.
I have found benefits though to structuring your WIP in a way that it can be merged into the trunk with minimal risk of breaking existing stuff. This is a mindset change around favoring adding new modules / components / endpoints without clobbering working code, especially for larger projects where the code is going to come in over the course of many releases.
Maintenance releases are done by going back to the tag or branch for your current prod release, making a new release branch from it, and pulling in whichever commits are needed.
I don't think it's a great idea to integrate with other work in progress, living on another feature branch. As far as maintenance releases go, strategies for resolving this are well documented here https://trunkbaseddevelopment.com/branch-for-release/#fix-pr....
It's not immediately clear when writing code that uses `useEffect`, when it's a very bad idea long term for performance or code clarity. This often shows itself when the test data is very minimal and then the real data is far more expansive.
I still love React, but these complex scenarios definitely show some of the limitations in React's rendering model that other frameworks like Vue, Svelte, and SolidJS resolve.