All built-in LayoutResolvers are almost copy-pasted, they all have REALLY similar tests, documentation and the code/logic itself - but are kind-of hard to abstract due to the type-safety provided by each.
The first alternative that comes to mind is to code-gen these, but I personally don't like code-gen, but if enough evidence is shown, that it indeed improves this package quality, we could look into it.
The other alternative that comes to mind is highly coupled with the mirror features that dart could improve in the near future, but is not at the point yet (it's basically the same problem that packages like mockito, built-value and auto-router face, which is also realted to the first alternative, the code-gen solution.
I still think there might be some space for other solutions, although I'm still not sure how.
Note: maybe CommonLayout and GranularLayout should be enough for most cases (and people can still implement the LayoutResolver on their own), but I still think that this is a problem that may increase as this package's lifespan expands, like if adding new built-in resolvers, or simply adding new functionality/fixes to each of them.
All built-in
LayoutResolvers are almost copy-pasted, they all have REALLY similar tests, documentation and the code/logic itself - but are kind-of hard to abstract due to the type-safety provided by each.The first alternative that comes to mind is to code-gen these, but I personally don't like code-gen, but if enough evidence is shown, that it indeed improves this package quality, we could look into it.
The other alternative that comes to mind is highly coupled with the
mirrorfeatures that dart could improve in the near future, but is not at the point yet (it's basically the same problem that packages likemockito,built-valueandauto-routerface, which is also realted to the first alternative, the code-gen solution.I still think there might be some space for other solutions, although I'm still not sure how.
Note: maybe
CommonLayoutandGranularLayoutshould be enough for most cases (and people can still implement theLayoutResolveron their own), but I still think that this is a problem that may increase as this package's lifespan expands, like if adding new built-in resolvers, or simply adding new functionality/fixes to each of them.