Apparently text in the Button is a modifier now? a...

# compose

[codeslubber]

Apparently text in the Button is a modifier now? and drilling down to the JavaDoc on Button helps zero. Crap, this is the major downside of Compose so far. The idea that docs and/or code completion would guide you through setting the basics goes back to the 80s?

[codeslubber]

found the answer in the samples, hey the release notes had a link!! good job there, but my complaint still stands, things that you cannot figure out are a step backwards…

[Zach Klippenstein (he/him) [MOD]]

What do you mean it’s a modifier? The button functions all take a standard children parameter where you can put a Text or anything else.

[Leland Richardson [G]]

Button { Text(…) } is the way to have a button with text

[Leland Richardson [G]]

sorry @codeslubber can you explain to me what you mean about this downside? i’m not sure i understand what the problem you’re referring to is

[codeslubber]

of course as I said I found the syntax @Zach Klippenstein (he/him) [MOD] and hey, I love it: if you are going to do composables, really do them: the button contains a text component, awesome, I was just bitching about the tools not being able to point that out to me.

[codeslubber]

@Leland Richardson [G] do you know who Rob Norris is? he’s a scala dude, talks at their conferences a lot, he has a rant where he now thinks the main thing that will kill Scala if it were indeed to die, is tooling. The argument is that the tooling that’s there is not helpful and it’s slow so people don’t enjoy working in the language as much. What I am saying is the clearest consensus item of tooling that goes back to QuickBasic in the 1980s is the editor suggesting completions, and/or walking you through satisfying the needed params/constraints, etc. If we go backwards on that front, to go forward on the reactive/compositional front, it’s a trade-off and one that some people might not like. So you save time from the components and the better composability, but then the tools are like pre-1988, that’s a bummer.

Not sure if there’s a simple solution. For instance in this case, how would I have known? I guess I should have guessed. Some tools (like IntelliJ and JBuilder) toyed with the idea of templatizing instantiation. Then of course there’s the ubiquitous Builder Pattern that took over the Java world. The Static Builder from Bloch 2nd edition addresses this directly: provides immutable construction and also tooling tie ins so you are walked through constructions that are often complex.

[codeslubber]

(Sorry for the verbosity, this is a thread though… 🙂 )

[Adam Powell]

I think you'll find we agree on the significance of good development tooling. 🙂 If you can share some of the specific situations you encountered, what you tried, and what you expected/think might have been helpful at those key points, we'll gladly take it to the appropriate folks on the team. Discoverability, starting from existing code or kdoc and connecting to common use cases and catalogs of, "what can I do from here?" is on our minds for sure.

[codeslubber]

I thought I started from the use cases?

1. how would someone know this is how buttons are done? simple code complete would probably not work because cc usually is just on a per call basis, that’s why I brought up templates
2. I complained before about how modifiers just kill cc b/c I can’t see what modifiers are possible in different contexts
3. then if I try to just navigate through docs, the links are not really enough, you end up kind of doing research
examples work and so it’s no surprise they are used in the release notes… the other thing this modification in particular is doing is reinforcing the notion of composability: if I am thinking ‘hey where should the text in the button come from?’ and then think ‘a text component’ then I am halfway there (I did think that before going to the docs, problem was I thought you might want me to pass the Text to the Button)… don’t want to make it sound like I am saying this challenge undoes all the great things about Compose, reiterating this is the right track/direction for sure…

[codeslubber]

Guess I killed these 2 threads… RIP

[Adam Powell]

not killed in the sense of shouting into a void or anything, it's good feedback that will be folded into the associated design discussions 🙂

[Zach Klippenstein (he/him) [MOD]]

Modifier discoverability is a big pain point for me too. Impossible to know from code what modifiers actually have any effect in a given context, or which modifiers even exist, unless the component author happened to include that information in the documentation. I usually end up going to Modifier and asking IntelliJ to show me all the implementations of the interface to find something that looks useful.