MVCoconut/Lobby

grepsuzette

@grepsuzette

if I encapsulate with a ParentView and even a Model (V.num in this case becomes an @:attr and setVal loses its default callback) I have the same problem. There has to be a secrete recipe!

serjek

@serjek

i think defaultValue in input is set only once per mount. did you tryvalue instead? and maybe adding <div>${Std.string(num)}</div> will also make sense at least for debug

grepsuzette

@grepsuzette

while drinking my wine I can confirm the example works with value instead of defaultValue, well at least I am not blocked anymore! will see how it goes in my app in a little while, thank you

Juraj Kirchheim

@back2dos

coconut.vdom set defaultValue and value directly (i.e. the properties of the DOM API), whereas react has some odd opinionated way to apply these differently ... defaultValue corresponds to thevalue attribute which provides the initial value for the value property ... it is also the value that's assumed by the value property if the parent form is reset ... so long as the user hasn't entered a value on their own (or value was set via JavaScript), then altering defaultValue will alter the input's value

serjek

@serjek

that didn't work for me in RN

but yeah RN has some workarounds for value/defaultValue to avoid blinking during render

Juraj Kirchheim

@back2dos

if it doesn't even work in react-dom, there's no reason it should in react-native ^^

serjek

@serjek

just wanted to explain why I suggested to use value on the first place :D

Juraj Kirchheim

@back2dos

you can do

@:ref var field:InputElement; function render() <><input type="number" ref=${field} />...</>; function viewDidMount() untilUnmounted(Observable.autorun(() -> field.defaultValue = num))

to make it work in react-dom, but that's not overly advisable ... in essence you either have to live with the differences in behavior, or you can make a separate view just for text inputs that behaves consistently

grepsuzette

@grepsuzette

@serjek yes value even works in my app. I don't know if it will in every case, but I put the recipe I found in some input snippet in my text editor to not have this question next time.

Juraj Kirchheim

@back2dos

be aware though that when you use value, you probably also want to read it back (in onchange or oninput), otherwise unrelated rerenders can overwrite the user's input

grepsuzette

@grepsuzette

yes i do it this way

I was wondering reading the doc, can (should) implicit attributes be used for async webservices (you know, like tink_web routes, http calls)?

Juraj Kirchheim

@back2dos

I'm gonna go with "no" ;)

grepsuzette

@grepsuzette

care to elaborate? I ask because I have also the same instinct, but I can not put words on it

Juraj Kirchheim

@back2dos

good uses for implicit attributes are cross-cutting concerns, e.g. localization, logging, tooltips, notifications, theming, etc.

grepsuzette

@grepsuzette

yes, like unimportant stuffs

Juraj Kirchheim

@back2dos

hmm, well ... if you have multiple languages, then showing the right one makes the difference between a usable and an unusable app ^^

but uhm, yeah ... it's not really a "feature" ... it's just something you have to deal with in a lot of places

you can also pass around services via implicit attributes

but, well, I would argue you shouldn't even pass them around via explicit attributes ^^

services should be passed into the model layer

grepsuzette

@grepsuzette

hum. that's right!

ok, i agree. thank you :)

Juraj Kirchheim

@back2dos

and as much as I hate to admit it, I do have a few projects that have an AppState model that's available at the root and is accessed via @:implicit from way too many places ... but it's always a small interface that doesn't introduce too many problems

so yeah, I guess what I'm saying is that it's fine to put services into models and it's fine to pass those models around implicitly, but the more widely such a model is accessed, the narrower its interface should be, otherwise the coupling will strangle you at some point

grepsuzette

@grepsuzette

Is there a way to ask for a certain view to be manually unmounted. Or how would you do it? Here is the case:

There's this bootstrap function I have to open modal windows (modal dialog or popups).
static function modal(view:RenderResult) { divModal = document.createDivElement(); /* add some classes to divModal*/ document.body.appendChild( divModal ); Renderer.mount(divModal, view); }. Also something like static function modalClose() document.body.removeChild(something);
One little piece of view that I want to show in that modal window has a lifecycle method ( override function viewDidMount() { var handle = setInterval(someTask,4000); beforeUnmounting(() -> clearInterval(handle); }).
But of course the beforeUnmounting() is never called because it is injected artificially. And someTask keep on running.
Any thoughts on this?

grepsuzette

@grepsuzette

I'm aware how I originally made this small modal system and even my question ("a way for a certain view to be manually unmounted") go counter the philosophy of coconut. But to make a reusable component such as Modal work very quickly, whatever the app, doing that without injecting the RenderResult seems difficult to me. So I'm like kind stuck in the middle ^^

grepsuzette

@grepsuzette

but hum, I think it's actually not that hard now that I wrote all this :eyes:. A <Modal view={modalView} /> can be put in my App view, and in its own render() it can have <if {modalView != null}> and otherwise it renders nothing, then the lifecycle methods would likely work

Juraj Kirchheim

@back2dos

if it's any help, the last code block of this comment implements a (minimalistic) modal system for coconut: https://github.com/MVCoconut/coconut.vdom/issues/45#issuecomment-980658227

grepsuzette

@grepsuzette

I will take a look now, thanks. I spent a few hours to realize I wrote @state somewhere instead of @:state -_-

grepsuzette

@grepsuzette

yes excellent, can show several windows, can be positionned or show a modal window. Wow. Definitely good (even though at first without restyling it it was difficult to see)

grepsuzette

@grepsuzette

In my console there is "Warning: Use the defaultValue or value props on <select> instead of setting selected on <option>.". This is in a <select ...><option selected={bool}>....</select>. But when I try to use value= on the <select> it seems it is not recognized by tink_domspec. Is there something to do here? (the warning is annoying me although it works)

Juraj Kirchheim

@back2dos

Sounds like react being a smart ass ^^

Juraj Kirchheim

@back2dos

ah, yeah: https://reactjs.org/docs/forms.html#the-select-tag

I wonder how that's even supposed to work for multiple selects ...

ah, you can pass a value

use preact then :D

grepsuzette

@grepsuzette

is it a sin to want to have a @:computed var endpoint : tink.web.proxy.RemoteEndpoint = ... on a model? If not, I get the error below:

tink.web.proxy.RemoteEndpoint is not observable, because tink.web.proxy._Remote.RemoteEndpointData is not ↪observable, because Field headers of { scheme : tink.web.proxy._Remote.Scheme, ?query : Null<tink.web.proxy.QueryParams>, ?pathSuffix : Null<String>, ? ↪path : Null<tink.web.proxy._Remote.PathFragments>, host : tink.url.Host, ?headers : Null<tink.web.proxy._Remote.Headers> } needs to have write access never

Any thoughts? :0
I may as well keep it in a regular var, it's just I am starting thinking about rescue servers, and thus endpoint that can change

serjek

@serjek

you can always set @:skipCheck meta to get rid of such errors

although, it doens't answer the question if this is a valid way to go

grepsuzette

@grepsuzette

I never realized @:skipCheck was for this :thumbsup:

Juraj Kirchheim

@back2dos

it's the coconut observability equivalent to untyped ^^

grepsuzette

@grepsuzette

could RemoteEndpoint be made immutable however? more a question for the haxetink group maybe

Juraj Kirchheim

@back2dos

yep

Peter Achberger

@Antriel

Just ruminating: If I wanted to make an electron based HTML game "Player", i.e. a wrapper around a game, for dev UI and such. On top of the main reason – accessing file system directly – I would like to be able to quickly hack around adding UI for whatever the game might need.
Issue is, I am not sure what tech to use for something like that. Immediate mode and HTML don't seem to go hand in hand, and I've never really found any library I've had good experience making UI with. Not counting coconut, as that's a mixed bag and not suited for hacking around.
Any ideas? :)

Juraj Kirchheim

@back2dos

https://github.com/cannerycoders/imgui-njs ?

depends a lot on what you need ^^

I find html+css very comfortable for creating UIs, but that's just me ^^

Where communities thrive

People

Repo info

Activity