But it does seem like a big miss on their part. But, like i said, the beauty of compose is that you...

# compose

[mattinger]

But it does seem like a big miss on their part. But, like i said, the beauty of compose is that you can see the source code and actually understand most of it (try that with the FAB class in material design library).

[henrikhorbovyi]

Cool... I'll try it

[henrikhorbovyi]

Thanks mate

[Louis Pullen-Freilich [G]]

The reason there is no enabled parameter or similar is because FABs represent a primary action on the screen, and according to Material Design specifications they should never be disabled.

Typically it is recommended to use something else instead of a FAB to show a temporarily unavailable action

[dewildte]

IMHO FAB should be disabled after a click if it navigates the user to another screen or during a transition. This prevents odd bugs caused from users who get impatient and spam the button.

I worked for a company that had a QA that did this kind of thing. He just spammed buttons constantly trying to cause issues. He was a living chaos monkey.

[alorma]

@dewildte been there LoL, reports were funny: "hit the button 5 times, rotates the screen, go back, App crashes"...

[mattinger]

I had a qa person once that liked to disable all browsers and things like play services and see what the app did. Let’s just say it did not behave well between the login being oauth and requiring a browser and the play services being disabled causing the maps to be unavailable.

[henrikhorbovyi]

In my case I want to create the following scenario:

[henrikhorbovyi]

It's a sign up flow and when the users input information (in this case a name) the FAB will be enabled

[henrikhorbovyi]

@Louis Pullen-Freilich [G] do you recommend another component instead of FAB?

[Louis Pullen-Freilich [G]]

Maybe just a Button then? 🙂 I don’t think a FAB fits this use case - a FAB should represent an always available action, like starting a new conversation