Is it possible to refresh the UI without using Observables?

How-to Discussions
1

For example, in React there is the .forceUpdate() method.

Is there a similar thing in Fuse?

(I’m writing a library integration with Fuse, using Fuse’s built-in observables would be really awkward here…)

2

Awkward “here”?? Here where?

and yes I believe you can, like for Each you can just use an array, but you’ll just have to keep replacing the arrays:

<JavaScript>
    function update(newArr) {
        exports.items = newArr;
    }

    module.exports = {
        items: [1,2,3],
        addItem: function() {
            update([1,2,3,4]);
        }
    }
</JavaScript>
<StackPanel>
    <Each Items="{items}">
        <Text Value="{}" />
    </Each>
    <Clicked Handler="{addItem}" />
</StackPanel>

Yet I still don’t know why you would want to do this, please elaborate

3

No, this is not possible from JS currently. Edwin’s example is incorrect.

Can you elaborate on why Observable’s would be awkward for your use case?

4

Hi!

Observable is the low-level primitive for communicating from JS to Fuse. For now, using observables directly is the recommended way of updating the UI.

However, it is possible to write JS libraries that observe objects an do automatic change detection. For example, we are working with integration of Angular 2 with Fuse, where Angular’s change detector will work out of the box, and map the result to observables.

We are also looking at providing other utility libraries that will take a plain JS object and convert it to an observable tree.

5

I’m the lead developer of Back I/O (http://back.io). It has it’s own object change mechanism that detects changes to domain objects, streams them to the server, and thus needs to provide it’s own mechanism for observability. It’s very easy to integrate this with React, because you can simply call .forceUpdate() when one the desired domain objects changes. With the current state of Fuse observables, a proxy / intermediate representation would need to be built and kept in sync in order to keep the back end synced to the front end.

As a general library design suggestion, I think supporting your own mechanism for observability is worthwhile, but I believe that forcing developers to use it is a bit on the onerous side, as other developers / frameworks could be using their own methods for observability.

But I had a feeling Observable had low level bindings, could these bindings be exposed in some way for advanced use cases?

6

Thanks for the explanation Paul. Back.io looks pretty rad!

We appreciate the API suggestion. However, as our platform and others work in fundamentally different ways, exposing different update mechanisms (especially ones that give JS more direct control for updating the UI) just aren’t the best fit for our solution right now. As we’re still in beta, this might change; perhaps in the future we also support something like forceUpdate, but we must consider the implications first, especially that abusing such a mechanism can have potentially detrimental consequences concerning UI performance. Not saying that your solution would be an offender in this case, but I think you know what I mean :slight_smile: One of the primary goals with Observables is to completely separate JS and the UI, and let the UI/databinding be the driver for updates, not JS. This is in stark contrast sometimes to how people are used to working and building frameworks for the Web, and we can understand how that may be confusing or frustrating, but I think it’s important to understand why we’ve made the choices we have regarding our design and why it’s important.

The other side of this of course is that we think it’s great that you’re looking into Fuse compatibility, and we’re happy to help however possible. Are you on our slack channel? I’d be happy to discuss how we can help you more in detail there if you’d like. I’m @jake there; not terribly hard to find :slight_smile: