Material-ui: Rename Fab component to FAB or FloatingActionButton

[haysclark]

The Fab components capitalization is a bit misleading as its an acronym; one would expect it to be named FAB; however, FloatingActionButton would be ideal for clarity and consistency with the rest of the Material-UI API.

• [x] This is not a v0.x issue.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Context 🔦

Abbreviations and Acronyms hurt a projects readability, as they add to cognitive load, tribal knowledge, and are often considered a 'code smell'. Grammatically, the main exception would be acronyms that are universally used in everyday language, such as LASER. 'Fab' is also used as an abbreviation in words such as prefab which is short for prefabricated, which makes the meaning harder to grok if you do not know the context.

Google uses a mixture of _Floating Action Button_ in their documentation and they do use _FAB_ after explaining the acronyms origin. Their various Google APIs also uses a mixture of FloatingActionButton and FAB as in acronym form, usually when FAB is combined with another component. I have yet to find any Google API's that have used FAB as an abbreviation for the actual button. Lastly, to be fair and play devil's advocate, I must admit that 'Fab' does show up in Angular docs; however, I would argue that this is a side effect of their documentation generation tools, as the API is lower case kebab-case.

Lastly, while renaming material-ui/packages/material-ui/src/Fab/Fab.js to material-ui/packages/material-ui/src/FAB/FAB.js would be more clearly show that the word is intended as an acronym, it might also create issues for users with case insensitive operating systems. I would thus recommend to go with material-ui/packages/material-ui/src/FloatingActionButton/FloatingActionButton.js, which would avoid any linting errors that FAB might introduce and be much more obvious to individuals less savvy of Material Design jargon.

Thank you for your time and consideration.

[mbrookes]

Hi @haysclark

Thanks for raising the issue. If memory serves, we originally had the component name as 'FAB' in the PR to extract it from the button, but opted for Fab to be consistent with the PascalCase naming of all the other components.

FloatingActionButton is rather verbose. I appreciate autocomplete can solve the keystroke count, but as a component name it's a bit of a mouthful!

I accept that FAB is quite Material Design specific, but then, so is the component that it renders.

Leaving open for now for others to comment, but I believe there was conscious thought already put into the naming choice.

[joglr]

I like the verbose FloatingActionButton, since the other names convey little meaning, unless you know the abbreviation. I agree though that it is a bit of a mouthful, but I still think the long name is better. There's already other components with such long names, such as BottomNavigationAction.

[liesislukas]

I'd like to leave Fab naming as it is.
Huge name & breaking change for just a small benefit to people who don't know the abbreviation yet, which I believe can be learned really with a minimum effort. Would not like to have such a long name for Fab inside my codebase.

[oliviertassinari]

I agree with @liesislukas here. People find that we release too many breaking changes. The name of the component match our acronym convention:

• CssBasline over CSSBaseline
• Fab over FAB
• NoSsr over NoSSR

I'm moving the concern to v5.

[el1f]

Agree with @liesislukas. I think the amount of people who aren't familiar with the concept of a FAB have enough context to get all the information they need right in the documentation for the FAB itself. Changing to FAB would create a lot of inconsistency too as @oliviertassinari points out.
Can we just keep it as is without creating too much of a need for codebase refactoring please?

Also, IMO full caps acronyms in React components are quite a mess since coming from other languages where full caps means that the variable is a constant could lead to all sorts of misunderstandings.

[mbrookes]

Let's put this one to bed.