Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 02 00:13
    dependabot[bot] labeled #31
  • Jun 02 00:13
    dependabot[bot] opened #31
  • Jun 02 00:13

    dependabot[bot] on npm_and_yarn

    Bump simple-plist from 1.1.1 to… (compare)

  • May 01 07:29
    back2dos synchronize #91
  • May 01 07:29

    back2dos on v1

    Add key value iterator to Child… (compare)

  • Apr 28 23:26
    dependabot[bot] labeled #30
  • Apr 28 23:26
    dependabot[bot] opened #30
  • Apr 28 23:26

    dependabot[bot] on npm_and_yarn

    Bump cross-fetch from 3.1.4 to … (compare)

  • Apr 28 21:11
    dependabot[bot] labeled #29
  • Apr 28 21:11
    dependabot[bot] opened #29
  • Apr 28 21:11

    dependabot[bot] on npm_and_yarn

    Bump async from 2.6.3 to 2.6.4 … (compare)

  • Apr 26 13:20
    darmie opened #94
  • Apr 10 17:59
    dependabot[bot] labeled #28
  • Apr 10 17:59
    dependabot[bot] opened #28
  • Apr 10 17:59

    dependabot[bot] on npm_and_yarn

    Bump minimist from 1.2.5 to 1.2… (compare)

  • Apr 02 18:09
    back2dos synchronize #91
  • Apr 02 18:09

    back2dos on v1

    Slightly better Attribute imple… (compare)

  • Mar 31 09:19
    kevinresol commented #59
  • Mar 31 09:18
    kevinresol commented #59
  • Mar 29 16:28
    back2dos opened #82
Kevin Leung
@kevinresol
yeah I think my app can run without a view. but my views can't run without the app data.
Juraj Kirchheim
@back2dos
:D
Kevin Leung
@kevinresol
mainly because my models store a reference to a tink_web remote instance
now whenever I wanted to test my view isolated I need to prepare a remote
I think I prefer #1 in most of the cases but it is not very ergonomic when it comes to optional attribute
and I even proposed to add @:promised var data:Data1 as a shorthand of #1
Juraj Kirchheim
@back2dos
yeah ... ideally the model wouldn't really depend on a remote proxy
one option is to make a @:genericBuild class Like<T> {} that takes an interface/class and returns a structure corresponding to it
then you can go @:constant var services:Like<Remote<Api>> and you can stick in a remote, but during tests just an anonymous object that returns what you want it to
or you can have an interface for your model and then one implementation is build on remotes and another is just a mock that is easy to set up for tests
grepsuzette
@grepsuzette
I have ModalWindow extends View.
And in the App class, static function modal(modal:ModalWindow) { ... ; Renderer.mount( div, modal); }.
But the second argument of Rendered.mount has to be RenderedResult; so what is the recommended way to render a view? (render() is private, so that's not it right?)
grepsuzette
@grepsuzette
to answer my own question, for now I can modal(view:RenderResult) and then modal(<ModalWindow>..</ModalWindow>), should be good enough
Juraj Kirchheim
@back2dos
yep
Thomas J. Webb
@thomasjwebb
How feasible is it to use something like antd (https://ant.design) with coconut or just haxe-react? I'm having issues making haxe externs for antd's typescript but also wondering if there will be other snags I'd hit trying to use its components, preferably in a coconut-ui-based app.
Thomas J. Webb
@thomasjwebb
Answering my own question - not very
grepsuzette
@grepsuzette
class Team implements coconut.data.Model {
    @:editable var color : String;
}

class World implements coconut.data.Model  {
    @:editable var colors : List<String> = List.fromArray(['red', 'green']);
    @:computed var teams : List<Team> = colors.map( k -> new Team({color:k}) );
}
In this example, any time colors will be edited, I think the objects in teams will be entirely rebuit. But when each team is complex enough, with @:loaded and what not, it is not very good. I am trying to find a way for them to persist but keeping @:computed if possible. Or is there a better approach
Kevin Leung
@kevinresol
Depending on your need you may use some cache (e.g. a StringMap) to store the teams?
grepsuzette
@grepsuzette
ah yes, k -> if (in cache) else put in the cache. Yes thanks :)
Juraj Kirchheim
@back2dos
in @:computed you can also access the last value as $last which is an Option (because on the first computation it is None) ... it's a little less straightforward, but since the previous value is discarded after the computation, you need not worry about keeping too many stale values around
grepsuzette
@grepsuzette
class V extends View {                                                  
    @:state var num : Int = 0;                                          
    @:attr var setVal : Int->Void = (n:Int) -> num = n;                                                                        
    function render() <>                                               
        <input type="number" defaultValue={Std.string(num)} />          
        <button onclick={setVal(24)} value="24" />                  
        <button onclick={setVal(37)} value="37" />                        
    </>;                                                                
}
this renders _0__ [ 24 ] [ 37 ], however on the react-dom backend (only), clicking the buttons 24 and 37 won't change the input. I think this is a problem that can not be fixed for now and instead it has to be worked around, but does anybody understands what's wrong in the first place?
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