feat: checkbox for inversion of visibility value

[FabienArcellier]

implement #354

This PR implement the reverse option that allow a developer to reverse the visibility logic. It also implements binding persistence when the user returns to Yes

[madeindjs]

There is a shorter syntax

Suggested change

	@input="
	(ev: Event) =>
	setVisibleValue(
	component.id,
	component.visible,
	(ev.target as HTMLInputElement).checked,
	)
	"
	@input="setVisibleValue(component.id, component.visible, $event.target.checked)"

[FabienArcellier]

My IDE raises a typing error with this syntax.

[madeindjs]

It's just a bool, no ?

Suggested change

	visibleReversed: Optional[Union[bool]] = None
	visibleReversed: Optional[bool] = None

[ramedina86]

Let's do this without modifying the root of the component.

Avoid having visible and visibleReversed at top level. They're closely related and should form one entity. Reversed it's also not relevant for undefined, true or false.

We can do

visible: {
  "reversed": true,
  "expr": "active"
}

So the TS type would be something like...

boolean | { "reversed": boolean, "expr": string }

[FabienArcellier]

visible: {
  "reversed": true,
  "expr": "active"
}

I was hesitant to make it a single entity. I gave it up. Certainly the 2 attributes live together but they do not have any particular management rule like content could have. These are component parameters.

I would therefore prefer to keep them at the same level as the other parameters of a component because they have the same level of importance. The interest in nested unnecessarily complicates the data structure.

I would rather rename them:

{
	"visibleExpr": ""
	"visibleReverse"
}

Would that be enough?

[ramedina86]

I'd prefer not, since visibleReversed is only relevant when there's an expression, not when there's undefined, true or false.

Another option can be to include support for ! in the expression evaluator (or hack it and store it inside the expression at the start). I believe the state elements are \w regex so you could easily do that.

[FabienArcellier]

I'd prefer not, since visibleReversed is only relevant when there's an expression, not when there's undefined, true or false.

Another option can be to include support for ! in the expression evaluator (or hack it and store it inside the expression at the start). I believe the state elements are \w regex so you could easily do that.

keep the custom value when developer switch visibility. In the visibility part, I had a behavior that frustrated me a lot. When I switch the visibility to Yes, I lose the content that is saved in the custom part. Sometime I just switch to make a check in the IDE.

Would it be possible to treat it this way?

{
	visible: {
		expression: True | False | "custom"
		binding: str
		reversed: bool
	}
}

usage of expression evaluation only if we implement dedicated builder block everywhere. I would advocate to use the expression evaluation only if we create a dedicated builder block we would apply everywhere we manage condition as for the field Show All Option in Pagination for example, .... Otherwise, I would advocate to implement the checkbox.

[ramedina86]

Makes sense and this looks good, happy to move forward with it.

Let's make sure to make it backwards compatible (I'm guessing should be an easy fix via auditAndFix)

{
	visible: {
		expression: True | False | "custom"
		binding: str
		reversed: bool
	}
}

[FabienArcellier]

@ramedina86 Since the implementation of pydantic, the structure of the ui.json file has been evaluated on the backend side. I had to implement the fix processing when loading the file before it was integrated into pydantic.

[ramedina86]

That's a good point...

[ramedina86]

Hey, what's the status of this?

[FabienArcellier]

Hey, what's the status of this?

I think it's ready to merge