Instant inline editing for data binding input

[nickneustroev]

PROBLEM:

I prefer not to use the data format popup and usually I write and edit data formats by hand in code. And actually it doesn’t bother me to deal with the code in such cases despite the fact that I’m not have a coding background.

The problem here is that usually it takes some time to reach out the code of the exact attribute/event/etc.
First you should click the binding button. Then you wait till the “Data Binding” modal shows up. Then you click “Code”. Then you edit code and after that you click “Select” and wait till the window disappears.

Or you can open the page or server action in the editor and change it. That’s why I always work with the page in the “Split” mode. But it is inconvenient too: you need to find the desired binding and keep focus on it.

PROPOSITION:

Maybe it would be better to make expressions editable inline?

It should be regular one-line input by default, but transforming in the full-height textarea when needed.
One option is if textarea opens up after focusing on input. I find it preferable.
Another option is a button or arrow near the input. And when you click on it, input transforms to textarea and vice versa.

It would be even better if textarea would take all width, maybe like this.

Also, as I don’t use the “Design” tab in “Data Bindings” modal, for me personally it would be better if the “Code” tab would be default. But I can’t say for everyone here.

What do you think about this idea?
How do you personally edit data formatters?

[karh]

I like it

[sid]

Once upon a time, there were no stupid bubbles/badges in the UI.
And you could just edit code stuff directly as you propose.
But I think it was in version 3 that this was changed, and I was too busy working to protest it, and no one else did.
Maybe 2022 will bring in some changes in this regard. Although I highly doubt it.

The bindings and picker stuff has been improved A LOT this year and are in a really good state as of now. If changing this UI would break it, I would rather have the extra clicks.

The purpose these annoying weirdly colour-coded bubble serve, from my perspective, is that its more visual, and easy to delete when there are multiple expressions somewhere.

[nickneustroev]

@sid

The purpose these annoying weirdly colour-coded bubble serve, from my perspective, is that its more visual, and easy to delete when there are multiple expressions somewhere.

For me, I can’t understand, what the use of them in current state.
I can’t see nor edit the expression.
Even if these inputs would suddenly disappear, I won’t notice it.

@sid

and I was too busy working to protest it, and no one else did.

Maybe there were no protests because one line input wasn’t convenient to use for editing anyway.

I found this old FR with the suggestion to do smth about it. Data binding input enhancement

@sid

If changing this UI would break it, I would rather have the extra clicks.

Here I agree. Changes only matters if it come with stability.

[George]

As Sid indeed explains we used to had this. However then 90% of all the problems were related to bad writing of expressions. Making typos and errors.

So that is why we introduced the visual pickers and moved code writing to the background.

For the most expressions you should used the visual pickers. They are quick to access and stop you from making errors.

If it comes often that a specific expressions aren’t possible with the visual pickers, you should add a feature request to improve those.

As last resort indeed we have code view but that should be indeed only if everything else fails.

[JonL]

Yeah. It’s a little thingy for the plebs who make 95% of the user base. It’s an understandable move.

I always go to code but my opinion on this matter is not relevant and I respect that.

[nickneustroev]

George, thank you for your response.

I’m personally not comfortable with visual Data Format editing. But I understand that some users like it.
Maybe this question deserves its own separate discussion.
But my point here is that in context of this FR it doesn’t even matter how comfortable the visual editor is.

Because even with the most perfect smoothless editor, in many cases the fastest approach still would be just instant manual code editing.

Sometimes you just need a simple little change, like changing a number or operator. It takes 1 second via code, but much longer through visual way.

Making binding input editable again doesn’t affect users who work with visual editor.
It just makes life easier for many other users who already successfully edit expressions into the code directly.

[nickneustroev]

How about a little poll.

Do you use visual Data Formats editor?

(To be clear, question only about Data Formats window. It is not about Data Binding window.)

I am myself using Data Formats editor, but only as cheatsheet, to see what expressions available and how to write it correctly. So it doesn’t counts as using.

• I use Visual Editor.
• I write expressions via code.
• Both ways

[Teodor]

@nickneustroev

Sometimes you just need a simple little change, like changing a number or operator. It takes 1 second via code,

Well as George explained above that was a big problem before. Most of the users editing code, writing wrong expressions (yes even the simplest ones) breaking things and then reporting their own mistakes as bugs.
If you want to change something manually switch to ‘code’ and change it, only if you are 100% sure what you are doing.

[nickneustroev]

Do I understand correctly that these problems were before the Data Formats Editor?
So users didn’t have other options back then except manual editing?

But since now there is a safe alternative way, why don’t allow editing again for ones who need it?
Regular users will still continue to use Editor.
And everyone happy.

[nickneustroev]

I still think that this would be a huge time saver for me and many other users, who prefer working with expressions via code. Need it for both frontend and backend.

Maybe it is possible to make it optional, so users can choose what way they prefer?