Some questions about syntax If all dimensions are in `dp` wh

Question

Some questions about syntax If all dimensions are in `dp` why can t I just put a number instead of doing ` lt number gt dp` What is the deal with the `+` operator in `style = +themeTextStyle subtitle1 ` for example I ve read the documentation about it but I still don t understand the need for it

ribesg · Answer

Since when are all dimensions in `dp`

Fudge · Answer

That s the way it seemed to me that all of the composables accept `DP`

miha-x64 · Answer

unary plus is really messy

Fudge · Answer

This is what I m talking about with the `dp` btw

miha-x64 · Answer

What is the type of `number dp` expression

Fudge · Answer

`DP` grin

Fudge · Answer

this is indeed the case regarding components < ribesg> ``` Component APIs specify their dimensions such as line thickness in DP with Dp objects ```

Fudge · Answer

``` IMPORTANT This global operator is TEMPORARY and should be removed whenever an answer for contextual composers is reached At that time the unaryPlus operator on the composer itself is the one that should be used ``` Hmm I m thinking the unary plus syntax won t be a thing in the future then

Leland Richardson [G] · Answer

the unary plus will indeed go away the design of effects will be simplifying

Leland Richardson [G] · Answer

regarding dp I believe we are trying to draw a hard line between dp and px as units and this was what we landed on open to suggestions on what we could do better

Leland Richardson [G] · Answer

if you just have `Int` as the type then there is no compiler help to tell you what kind of units it s expecting and you have to rely on say the parameter name `widthInPx Int`

ragunathjawahar · Answer

IMO I like the unary `+` operator Because most of the time code becomes hard to understand and maintain because we mix logic and effects The `+` operator visibly makes a distinction and helps identify an effect This has added benefits during code reviews and architecture Whenever I see an effect I could use the visual cue to ensure that the effect does just one thing And also ensure that my effect does not have business logic in it i e My state gets updated outside the effect

ragunathjawahar · Answer

Also we could use tooling to ensure state mutation does not happen inside effects

Fudge · Answer

I like the tooling idea more slightly smiling face

Fudge · Answer

How often is it required to handle a `px` I come from Flutter where that is not even a concept

Leland Richardson [G] · Answer

< ragunathjawahar> this was kind of my original intent with the `+` It s strange at first but having a visual clue to tell you when something different is going on can be a good thing

Leland Richardson [G] · Answer

what i ended up realizing was that the things that make `Effect` special are pretty darn similar to what make ` Composable` special and i m trying to unify them though we are still thinking that maybe they need to be a little bit different

Leland Richardson [G] · Answer

on the tooling side the IDE will eventually make it more clear when you are calling something that is Composable or an effect visually and i m hoping that this is enough

Leland Richardson [G] · Answer

the problem with that is those visual clues aren t present in say code review

Leland Richardson [G] · Answer

< Fudge> good question APIs are still evolving so it s unclear everywhere it will be necessary but right now all of the drawing and layout APIs end up resolving down to pixels you re right though that these won t end up being used in user land code very often

ragunathjawahar · Answer

How would the unified API surface look like Is this something that you can share

Fudge · Answer

Thanks for great answers < Leland Richardson G >

Leland Richardson [G] · Answer

well my hope is that an effect is really just a composable function with a return value but so far we have required composables to return unit and that is being treated as an implicit assumption in several places that we re not sure we can break

ragunathjawahar · Answer

What happens if I try to add a `Text` to a composable function that is an effect I feel that the lines are getting blurry if the API tends to move towards that direction

Leland Richardson [G] · Answer

yeah that s a question we ve been asking ourselves as well I think my question is is that something that we should just lint against or should we prohibit it entirely at compile time I can t think of a good reason to do it or to want people to do it but perhaps there s a really nice pattern out there that we haven t discovered

Leland Richardson [G] · Answer

not sure how good of a reason to do it that is but if the math of it works out then i m drawn to the unification of the two concepts

romainguy · Answer

< Fudge> The underlying drawing APIs work in pixels

romainguy · Answer

Also sometimes you want to do pixel perfect drawing and it can be useful to use px as a unit

George Mount · Answer

FWIW we have 3 dimension classes that you commonly use Dp Sp and Px This allows you to have constants for these values in the code and convert them at runtime as needed For example if you want to specify that something should be exactly 2 pixels high you can do that even if the API accepts DP We think that most app developers would prefer specifying almost everything in DP with a few in PX and SP It is easy to get units wrong when they re naked floats When doing layout we also have IntPx to avoid any confusion of rounding errors

Fudge · Answer

I would like to see the usage percentage in practice and continue this discussion

romainguy · Answer

I m not sure it would be helpful This has the benefit of being explicit esp if you mix and match with the existing view system were all values are in pixels except when they re in dp and allows for pixel perfect layout and rendering when needed

Fudge · Answer

My meaning is that we would have `width = 10` when meaning `dp` `width = 10 px` when meaning `px` and `width = 10 sp` when meaning `sp` If 99 of use cases are `dp` then that makes ` dp` boilerplate in my opinion

romainguy · Answer

Given that all the existing APIs assume pixels when you do `width = 10` I think it would be a bad idea to go this way

miha-x64 · Answer

``` interface Dimen inline class Px Dimen inline class Dp Dimen inline class Sp Dimen ```

Leland Richardson [G] · Answer

FWIW if you re targeting an interface having it be an inline class will end up creating more boxing unboxing operations than you d expect and it would actually be a net negative to mark it inline

romainguy · Answer

Inline classes can cause a lot of boxing in general too

miha-x64 · Answer

I know that upcasting leads to boxing APIs should have overrides to avoid this

Leland Richardson [G] · Answer

but then the value of the `Dimen` interface goes away any function with `width Dimen` would represent an upcast

Leland Richardson [G] · Answer

it s hard to define APIs that leverage inline classes well

Leland Richardson [G] · Answer

i don t think the idea of using `Int` to represent Dp or Px and classes for the less common ones is a bad idea it just has trade offs like romain mentioned and we are trying to navigate those thoughtfully