After LD, sure.

I don't have a repro for this, but I got into a weird state where css changes stopped working. Recompiles/changes did nothing. Was stuck like this until I restarted the language server

Not sure if this is haxeUI or RC5 being weird though

Sometimes my UI disappears, and the AST between the two is actually different

Same with restarting language server

Language servers as been jaming up since rc5 for me. No issues with ast or css not applying.

@bright-gpu-74537 So DataSources can have infinite loops when trying to clear the data; This happens only when using a transformer that returns a different type then the type that is contained in the DataSource(i.e. a String in the DataSource will be transformed to a {text: i } so when we call clear on the DataSource we can't remove each item since the item returned with get will be transformed). I think that the solution should be that when we clear we call a handleClear function (that I would add to DataSource) and in that function we call the clear function of that data type(Array or List).

What do you think ?

We could also cache the transformation when clearing, set it to null, and when we are finished clearing we set it back to the cached transformer

well, i guess handleClear make sense, right?

i mean, then if its not an array or a list, something more custom, then the user can just override that and do whatever... if they wanted

yup thats what I thought; will implement and send a pull request

sounds perfect... thanks!

@bright-gpu-74537 PR made; travis build failed because: faraday requires Ruby version >= 2.3.;

oh? That recent?

ill check it out... more... ... ... ... travis... zzzz

yeah; looks like a boring task to maintain travis... 😛

To avoid package manager insanity you could probably try installing from source: https://docs.travis-ci.com/user/installing-dependencies/#installing-projects-from-source

@User - looking at your PR

do you think in the default impl for handleClear we should have the old method?

array and list DS's override it

though if it can get into inf loops maybe that a bad idea thinking about it

Looks like setting

native=true

on a dropdown causes some kind of catastrophic failure. I don't even get an error, the whole app thing just stops working as soon as it tries to create one.

it defo shouldnt fail, but for composite backends (openfl, kha, etc) its fairly meaningless

can you by any chance open an issue, just to track it?

it reality you dont really need to set it... native backends will do it via css:

the reason is its also a prop is because you can use it on "hybrid" backends (html5 for example)... you can have, for example, native dropdowns (html ) and composite, say, tabviews

even then i would probably use css: