Add advanced options to block settings

[pinarol]

We should add the advanced options field to the block settings:

Since every block has this option we'll always be showing the BlockSettings button. So we can also simplify the code that decides to render the BlockSettings button according to InspectorControls having fills.

[iamthomasbishop]

One big thing to note. We need to figure out how to more gracefully handle text input. Note: This is related to the other issue regarding scaling the inspector sheets.

Right now, we have very limited space, considering the input is only allowed space in part of a single row. This is a problem we're already experiencing with text inputs on settings sheets for images, links, etc.

I propose that we consider doing either of the following:

• Show a dialog (android) or alert (iOS) with a text input that allows the user to enter the text, submit it, and apply it to the sheet row. This isn't optimal, but seems like could be more straight-forward if we can use native components. Example:

• Bump the text input to the next line of the table row. This would give more horizontal space. Example:

• Open another bottom sheet that contains the text input so that the user has more space for entry

[jbinda]

Maybe we should also relay on number of chars that is allowed/defined for particular text input.

E.g. We define bunch of textinputs and we can set up max-chars for each of them. If we know that the amount of chars fits nicely to current space we have then we do not enter the extended editor.

On the other scenario we expect large amount of text here and then use one of the solution above.

We can achieve the same by e.g passing multiline="true" or type="textarea" depending on what will be the most elegant and intuitive solution. I have recently open an PR which bring the markup similar to web version so we can handle this case there.

IMO the BottomSheet solution that @iamthomasbishop proposed sounds the most interesting.

[iamthomasbishop]

Maybe we should also relay on number of chars that is allowed/defined for particular text input.

I might be misunderstanding your point here, but I don't think we'd want to set a max-chars limitation for text inputs unless absolutely necessary. This would be especially troublesome for long URLs, for example.

IMO the BottomSheet solution that @iamthomasbishop proposed sounds the most interesting.

Are you referring to the first example I shared above (the dialog/alert input)?

[jbinda]

Are you referring to the first example I shared above (the dialog/alert input)?

Yes but my point was that I like below solution most

• Open another bottom sheet that contains the text input so that the user has more space for entry

I never liked single-field input dialogs. I find them looks ugly :(
In general I used to use them (dialogs/alerts) in the way there were design for which is for receive action confirmation from the user or warn/inform the user

[iamthomasbishop]

I never liked single-field input dialogs

I would agree w/ that – I would much prefer one of the following (listed in order of preference):

• Use a nested structure, deferring content input to a sub-page/view
• Bump the input to a second line on the table row for more space
• Open a second sheet for text input, then hide sheet when submitted

If we can't do one of those things, then we should defer to a dialog as mentioned above.