Compose is Production ready? Okay, Compose will hit 1.0 stable in July? Great. I’m absolutely happy with the hard work which made compose almost ready for production But I think there are some areas that need more improvement to be fully production-ready for everyday use
Note: my feedback is based on latest compose release at the time of writing which is 1.0-beta08
Debugging:
the Issues related to Debugging are mostly around tooling, Live Preview is somewhat buggy, sometimes it doesn’t work, sometimes it is so laggy, sometimes it displays an ambiguous error message and Once I hit the refresh button, it renders without any problems. I know it is going to evolve over time with the next Arctic Fox updates but for now Live Preview isn’t a good option for complex components.
Another issue I’ve faced in debugging some compose code is the silent errors. Take a look at the next example:
What should that code display? Can you guess?
The answer is simply:
The inner Box is completely invisible, can you figure out why? because you haven’t declared a value for the alpha channel when you had declared teal700 color, To fix this we can simply add the alpha channel value:
You might catch that quickly but remember this example is simple enough to not be realistic, In a more real-world scenario you may have hundreds of colors in a single file & you are more likely to access the color from something like MaterialTheme.colors.primary , also, you may have deeply nested components that each parent could affect the appearance of its children with a customized theme.
All of those factors in addition to that there is no error propagation mechanism could waste your time debugging this ridiculous issue.
One of the proposed solutions to this issue is to throw an exception at the render time with a stacktrace that can help you track down the root of this issue.
Another less aggressive solution is to report a lint warning when you forget to provide an alpha value.
Thankfully, this issue got addressed by compose team at this commit and the latter solution has been the preferred way to deal with this issue.
Testing:
compose team wrote an excellent documentaion about testing composable functions. it contains the basics you need to get started, but once you have more complex components you can realize that things can get out of your hands easily, you’ll find yourself writing some additional boilerplate plus relying on some implementation details to write your UI tests which collides with the idea of making your UI black-box tested, Moreover it makes your test suite fragile & tightly coupled to the implementation.
Another problem with testing is not technically a problem but a feature request which is to be able to run some compose tests locally, this is not possible so far, though there is a promise to make that happen soon:
Coupled with fixed kotlin version:
Right now compose comes with a restriction that prevents you from using a higher major kotlin version than the version compose compiler uses. This was annoying, because, until 1.0-beta07 release compose was depending on 1.4.32 kotlin version, So, If you intended to use kotlin 1.5 in your project you get blocked and you will have to wait for compose compiler to update to 1.5 version. This restriction has been relaxed quite a bit with 1.0-beta08 release because now compose compiler has opted for kotlin 1.5 but the main idea still exists.
Conclusion:
Those are some of my reflections on the current state of compose, some of them if not all them are likely to be obsolete as long as compose is evolving rapidly.
Last but not least, Some people noticed that there are some performance regressions in compose compared to the traditional View system, but genuinely I haven’t investigated that yet.
