Datagrid Edit Styling

Is there an easy way to change the style of a datagrid field when it’s in edit mode? I thought maybe a State could work, but not sure what condition could be used to recognize that the row in the datagrid is in edit mode. See Loom for more details.

Thanks.

Solved it using a variable, text field and input field within a custom column in the datagrid. :slightly_smiling_face:

Actually no I haven’t solved it. Using a variable is causing the elements to be switched out in ALL rows in the datagrid, whereas I only want the row being edited to be switched:

Every element being on a row have the readonly state until edit is switch.
So you could style your component to look like what you want in edition, then add a “readonly” state and style them how they need to look like when non editing

1 Like

@aurelie What is the condition for the readonly state though?

Screenshot 2023-05-25 at 3.20.52 PM

Every element being on a row have the readonly state until edit is switch.

Its interesting… in the component I am not seeing any logic that changes from default to readonly state?

When I inspect the element, I am not seeing any variables (in weWeb of the inspector) change?

And I cant see logic on the other parts to display when the state changes?

I might be missing something.

Same, that’s what I was looking for too and I can’t see anything.

You do not need to add a condition here, the state is added automatically by he datagrid component.
It’s like the active state in the paginator text, or the checked in the checkbox.
We do not have a good way to push them for now, so you can easily see they are available. But we are working on improving this.

Maybe I am thick but I don’t understand what you are saying sorry @aurelie. @twinsticks are you following?

Here is my attempt to follow your instructions @aurelie but it doesn’t work for me.

I’m AFK k right now… I see that adding your own state with the name read only didn’t work…

One thing I have found a little harder to understand in the weWeb editor, is what state the app is in when you are in editing mode after returning from preview mode…

So maybe try going into preview mode in weWeb then clicking on your edit button on the table and staying in edit mode when you exit preview mode.

Apply styling you want to the element. Then go back to preview and test?

It looks like WeWeb pushed an update!? Thanks!

Ah! Great that worked out for you, but I was trying to help you solve a different problem! lol

I was looking to be able to conditionally change the look and feel when in edit mode, but I could not find the variable that changed the state.

I was actually able to see the the change to input fields on my end… so not sure if it was an update or a refresh?

Best of of luck with the rest of it!

I dont know. This gets weirder and weirder. The WeWeb behavior is inconsistent now, which is concerning. Seems pretty buggy to me.

Found the elusive readonly state! But it’s only on some fields, not all. Why?

Hmm…It could be that in the template, those fields dont have any different styling in that new state??? not sure…

So I think with the new states, that are not hover (standard alternative) you have to set the condition for when the state is used by the element.

Then you can create a variable that you set when something happens, based on the value in that variable, it uses the custom state you created? does that make sense?

I am not quite sure I 100% understand how the data grid works… but it might be that (right now) these prebuilt components offer some of the functionality, and we have to add the rest ourselves…

I am still playing around with it

If you can figure it out please let me know, thanks @twinsticks!

@aurelie Please let me know if this is a bug so I can submit a ticket. Thanks!

So I think what you were seeing at the start of this was a bug or some cache issue? The data table component given in the + element works as expected for me.

@aurelie it is still not clear what variable is changing when the edit icon is clicked to get to the edit view of the inputs?

What I found in regard to component states, was that after you add a new state, you need to set a ‘condition’ for when that state should be used. I am thinking this should be based on a variable change of some sort.

Then your specific styling for that state will show.

There are some things that did confuse me though…

There are some configuration settings that show across the states you have, default, hover, myNewState, etc…

To me, it looked like you could set them for each state, but in fact, they apply across all the states, so changing it just on the myNewState pane, actually changed it on all the others. Input placeholder text for example, it would be nice to be able to set that in each workflow state…

@aurelie it might be nice to be able to identify the component in the workflow tool and see the sates that are available… I assume that the idea is today is that we should use the same variable we use on the states condition, in the workflow tool to make any other changes… but it would be nice to just see the states name, when they are active (based on the variable) we can do some other ‘work’ on them…

Best

  • Each property of a component can be state “sensitive” or not. It’s up to the component to decide which ones. For WeWeb component we often make choices and what seems “functional”, but you can give feedback on this :slight_smile: (this is the same for breakpoints and responsive)

  • To know if a component has set the value to this state and not all the states, you can have a look at the green dot which appears when you change the value

  • When a component has a state, there are different ways to “activate the state”

    • The state is conditional, and the condition is true
    • The parent component push a state to one of its child (for example, the paginator push the active state on the text)
    • It’s a parent state which has “Apply to children” set to true
    • It’s a native state handle by WeWeb, like hover or active link
    • The component has it owns logic to activate a state itself

For input, they can have a “readonly” state, which is activated when you mark it as readonly. This state is also forced by the datagrid when the line is not edited.

Because we wanted to reuse existing components, the datagrid is using “normal” input. The logic for these inputs is to have a style, and overwrite this style when disabled (state readonly). The datagrid make them disabled by default, and cancel this when you edit a line. This is how you can differentiate them from edit or not. It’s a bit complicated, but that a technical constraint we have (we want to push a new way to do it with custom components)

States are very powerful, and there are a lot of different ways to have them set (user logic, component logic, etc). I hope things are clearer with these explanations, let me know if you need more :).

2 Likes

Thanks for the explanation @aurelie. I am still experiencing some inconsistent behavior though, which I think is a bug. In the screenshot below the Name, Email, Amount and Hours fields are all set to editable, yet only the Name and Email fields get the different visual treatment in edit mode. Why don’t the Amount and Hours fields get the same treatment? I do see the ‘readonly’ state exists on the Name and Email fields, but not on the Amount and Hours fields. The Amount and Hours fields are additional columns that I added to the Datagrid after binding the collection to the datagrid - perhaps that has something to do with it? More details in the Loom video.

Thanks!