im not dissing, just saying its a complex path, haxeui-hxwidgets already got some nice upgrades because of your app (ie, focus, image scaling)

Yeah.. add to that all the coconut stuff which i'm trying for the first time (but it's really close to haxe-react so I'm not too lost) and tink stuff too (like tink_sql) 😆

i didnt add those things, i suppose, because its simply never come up

yeah, coconut adds another layer of complexity for sure

Thinking mid/long term, this could become a real stack for me

I might go freelance to leave my shitty job, and being able to tackle native + web (and mayyybe mobile) with high productivity (once the edge cases are solved xD) could be nice

its a nice stack for sure, ive never really used coconut tbh, so im a little in the dark, but the if it works with haxeui-hxwidgets thats certainly pretty damn swish (its one of the more... ... particular... backends)

Yeah I'm heading straight for the issues for this poc x)

indeed

I don't want to validate a stack, start using it for real and then have the issues :P

makes sense... sensible

Hmm, found a workaround for my custom style disappearing issue but I'm not sure what to make of it..

Setup triggering the issue is ± this:

<Box>
  <if {someCondition}>
    <TextField ... />
  <else>
    <Label ... />
  </if>

  <Label .. />
</Box>

There are 2 possible bugs: - either I add keys to differentiate the labels for coconut, and then when someCondition becomes false the first Label "just" loses its styles - or I don't, and then the first Label is fine but second one gets some styles from first Label (kind of a mess, but one could argue it's normal without keys to help coconut identify who is who, when components keep state that coconut doesn't know anything about) So I went with keys, and am executing some code after changing someCondition to false in order to reapply styles for Label. So far, only this succeeded:

@:privateAccess label.applyStyle(label.customStyle);
label.invalidateComponent();

what about

label.invalidateComponentStyle()

?

though i dont really understand why its losing the styles in the first place tbh

Tried that, didn't work :x

Well, it doesn't really lose it; it's recreated and its styles are not applied

how is it recreated?

The difference I've seen so far is that it's being added to a parent container that is already "ready", which is not the case when first inserting

Coconut reinserts all components, that may give a behavior that you don't get without it

I get the behavior when adding new items too: last item is always missing its styles

one work around i can think of is to use actual css... rather than trying to set the custom style, but i sounds like something needs to change somewhere - just not sure where

Maybe coconut should call a method from container after updating its children?

Ok found another workaround from within coconut

Well, another place where to put @:privateAccess real.applyStyle(real.customStyle);

so when you add an item to a scrollview that already has, say, 100 items, it reinserts all of them?

With setComponentIndex, yeah

There will be things to optimize x)

i was going to say, wont that be insanely inefficient??

Still better than electron ™