Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Marek Kadek
    @KadekM
    at least so far in larger app I have
    so you can observe arbitrary input
    for example, observeInputElement, gives you back:
    trait InputElement { self: ObservableTag =>
      final val value: Observable[String]
    so the value is no longer property of dom element but is observable of strings
    the other side is react thing
    so if you want to hook one to another, source is what you observe, and sink is what you react
    one can be both of course (not yet implemented)...

    so you would get something like

    trait ObservableObservableTag {
    
      val tag: Observable[TypedTag[VNode]]

    instead of

    trait ObservableTag {
      val tag: TypedTag[VNode]
    (with events in same trait, that are automatically switched along with tag)
    Marek Kadek
    @KadekM
    if you run the repo, do project sample and do fastoptjs, open index-dev.html you'll see that button caption changes as input changes...
    sorry I know its very confusing, I didnt have yet time to put compelling example together
    basically prehaps in other words it could be said that by observing element you get back
    {
    ... various observable properties of element like value
    val tag: TypedTag
    val events: Observable[Event]
    }
    if you have instance like this you can render it and hook into its events, but it's static, it can't depend on other observables, which you can see by that TypedTag is not observable - you don't know when/how to re-render it - it can't change it's DOM state
    if you have something that reacts then
    {
    ... various observable properties of element like value
    val tag: Observable[TypedTag]
    val events: Observable[Event]
    }
    Marek Kadek
    @KadekM
    so to render the tag you have to hook it up to your re-render logic, but the tag emits each time component changes it's DOM state
    the events and other properties of course needs to come from new tag if it has been re-rendered
    so naively it would be
    val tag: Observable[(Event, Event ...., TypedTag)]
    and nothing else
    but I think one can hide it since events can be implemented by looking into the stream of that complicated type, taking the important part, and switching (combinator on observable) to latest stream

    thus by simply subscribing to events of

    {
    ... various observable properties of element like value
    val tag: Observable[TypedTag]
    val events: Observable[Event]
    }

    you'd get events even if tag gets destroyed and created again (thus producing different stream, but that would be hidden from consumer)

    I'll make some better example once Im done with it, that uses it without the need to understand internals, I think it would be much clearer
    Sorry about it, I'm just very busy with work :/
    Luka Jacobowitz
    @LukaJCB
    No, don't be! Thank you so much :+1:
    Marek Kadek
    @KadekM
    I pushed update now
    should be cleaner
    and implemented missing functionality
    Luka Jacobowitz
    @LukaJCB
    I'll check it out and give you some full feedback soon :)
    Marek Kadek
    @KadekM

    so you have like

    observe.any(input(`type` := "button"))(onclick)

    gives you thing which exposes you events

    if you want it to also to change caption based on something else
    react.at(observe.any(input(type:= "button"))(onclick))(value -> inputO.value.map(_.length))
    its still not very clear but at least now its feature complete kind of
    in the real app where I use it I have single subsribe at the end of the world, where it updates the DOM
    and if I want I can control/throttle it or something
    Marek Kadek
    @KadekM
    Let me know what you think, I'm curious :)
    Luka Jacobowitz
    @LukaJCB
    Sbt couldn't resolve com.marekkadek#scalatags-vdom_sjs0.6_2.11;0.3.0-SNAPSHOTfor some reason :/
    Marek Kadek
    @KadekM
    I published it now.I probably forgot
    Sorry about that
    Andrew Gaydenko
    @gaydenko
    @LukaJCB Are there plans regarding LukaJCB/rxscala-js#19 ? Or - still travelling?
    Luka Jacobowitz
    @LukaJCB
    Hey @gaydenko yeah I'm sorry for the delay, I'm at my family's over easter, but I've been able to spend some time looking at the problem and I'm still not one hundred percent sure how to handle it, because the response depends on the content type
    Andrew Gaydenko
    @gaydenko
    @LukaJCB I guess the aim of OutWatch (well, rxscala-js :smile: ) AJAX wrapper must be just a transforming of upstream code to Observable, that is without dealing with content (or any other smart defaulting) at all. User code must be the only dealing with content.
    Luka Jacobowitz
    @LukaJCB
    Well we could just have the response be js.Dynamic, but that doesn't seem nice
    Andrew Gaydenko
    @gaydenko
    May be to use this one? http://www.scala-js.org/api/scalajs-dom/0.9.0/index.html#org.scalajs.dom.experimental.Body Or, may be, it would be more handy just to have separated dedicated "observabilation" of this or that HTTP client.
    Luka Jacobowitz
    @LukaJCB
    Those don't really work, because of the internal promises that might fail, no? That would mean the user would have to see for themselves which responseType they'd like to parse and convert the inner promise
    and that also leaves the question what you do with application/json besides parsing it to js.Dynamic
    Andrew Gaydenko
    @gaydenko
    I guess it would be sufficient at first to have an opportunity to get a response body as bytes and as UTF8 string. Yes, I guess, API's client wants to decide how to treat response herself - as image, JSON, html, text, XML or anything else. JSON format isn't special in any sense, to my taste.
    At my use cases I use circe for serde on both sides. But it is just a single use case among infinite ones :smile:
    Luka Jacobowitz
    @LukaJCB
    Yeah I use circe as well
    So i'd just like a string either way