Channels
#compose
Title
# compose
p
Patrick Yin
07/29/2020, 12:03 AMAbout
@Previewthanks mate
g
gildor
07/29/2020, 6:43 AMBut they still will be there if you do not use R8
So you compile all you previews just to build debug version of your app
Doesn’t look very scalable thing, if you have multiple previews for every of you composable, you will end up with a lot of code if write project from scratch
Wouldn’t be a better solution to have additional source set for preview, which depends on you main source set but not used for compilation, something similar to testFixtures source set in Gradle
I understand, it looks nice to have preview defined in the same file and say that “it would be shinked by R8”, but I have feeling that it’s the thing which will bite you eventually
j
jim
07/29/2020, 10:59 AMWe would strongly recommend you have R8 enabled. If you don't have R8 enabled,
@PreviewCan you elaborate on what you mean by it not being very scalable?
g
gildor
07/29/2020, 1:54 PMNobody uses R8 during development
About scalability I want to say that you pay for every line of code by direct compilation time and by invalidation of already compiler code
So you have to compile all preview even if don't use them for debug or tests
So if you have hundreds components each of them probably have at least 1 preview, you compile all of them
What even worse, you change your preview, you now have to compile this module, if it changed abi, you have to run annotation processors on all upstream modules
So if non-abi change for our project in best case is 15 second, ABI change is at least 30 seconds
So I wouldn't like to have previews or test data in my main source set
j
jim
07/29/2020, 9:45 PMWell, yes and no. True: no one uses R8 during development, but the size in development isn't nearly as important. The original question was specifically about reducing the bytecode during a release build. Reducing bytecode during a debug build isn't nearly as important, except in sofar as it impacts compile performance, which brings me to my second point.
Your compose widgets should generally be in leaf modules because they shouldn't be depending upon internals of your app. For a well-structured app, this means that changes in your app won't cause the widgets to be rebuilt. Low-level widgets (the type used everywhere) are going to be written and then shouldn't change super often, so the scope of a build invalidation is typically small, assuming you have your build files properly configured.
That isn't to say that none of this is matters - build times are critically important - but there is probably lower hanging fruit than trying to avoid
@Previewp
Patrick Yin
07/29/2020, 9:58 PMI’ve found a way to make it work without enabling obfuscations. Sometimes you could not fully enable R8 for the project since it has some reflection usage might be broken. (yes, you could add -keep rules to proguard configuration, but you might not have time to solve all of the issues if you are on a big codebase). So I just tested, the easiest way is just enable R8 and in the proguard configuration, put:
Copy code
-dontobfuscate
-dontoptimizeAnd then it won’t obfuscate anything, and only remove unused methods. (@Preview methods)
So if you really want to remove preview functions on your debug build, you could do this. (But from my point of view, I don’t really care about Debug build’s size)
g
gildor
07/30/2020, 2:21 AMSo if you really want to remove preview functions on your debug build, you could do thisIt’s still build performance penalty, tree shaking is not free
the size in development isn’t nearly as importantI mostly agree, not very important, difference is minor (packing, installation)
Your compose widgets should generally be in leaf modules because they shouldn’t be depending upon internals of your appIt’s true, and what I said is for leaf module, the best case. But you also have hierarchy of modules, a lot of components are reused, or part of another component in another module, which itself part of another component and so on.
are going to be written and then shouldn’t change super oftenUntil you start working on some changes (or want to play with preview of some core component!) and getting close to full recompilation when you want to change something in those core widgets
but there is probably lower hanging fruit than trying to avoidI would love to hear about all those lower hanging fruits, but we very careful with build and configuration time, now most of time is obviously annotation processing, direct compilation and app packing And unfortunately all those “fruits” will not change one fact, you still pay by build time on amount of code which you have to compilefunctions@Preview
moving your `@Preview`s outside of your main modules does in fact get you significant savingsIt would increase amount of modules, adding modules not only boilerplate itself, but also increase configuration time (which will problem even with gradle configuration cache). I think custom source set, same way as it works for tests or for textFixtures is way to go, it allows you have preview separated from main app code without build penalty
I’m sorry if my comments sound harsh, I’m very appreciate work done on compose and very impressed even by current state of
@Preview👍 1
k
Karthick
08/02/2020, 6:14 PMIs it possible to do a restriction, that a preview function cannot be called from a normal or composable function
5 Views