canjs / can-simple-observable Goto Github PK

View Code? Open in Web Editor NEW

3.0 5.0 1.0 138 KB

Create an observable value.

Home Page: https://canjs.com/doc/can-simple-observable.html

License: MIT License

JavaScript 99.68% HTML 0.32%

canjs observable

can-simple-observable's Introduction

can-simple-observable

Core observable indicators.

Documentation

Read the can-simple-observable API docs on CanJS.com.

Changelog

See the latest releases on GitHub.

Contributing

The contribution guide has information on getting help, reporting bugs, developing locally, and more.

License

MIT

can-simple-observable's People

Contributors

Stargazers

Watchers

Forkers

frank-dspeed

can-simple-observable's Issues

simple-observable/resolver should know dependencies

AsyncObservable cannot return a value after previously resolving

An AsyncObservable cannot return a value from its getter if resolve has already been called.

That means the observable below cannot be used to toggle from 0 to 1 and then back to 0:

	var asyncObs = new AsyncObservable(function(lastSet, resolve){
		if (value.get() === 1) {
			resolve(1);
		}

		return 0;
	});

Should resolver always dispatch an event?

In order for the can-define value behavior to handle more use cases that streams can handle, maybe resolver should be able to resolve the same value multiple times.

I would like to be able to do something like this in order to keep the value of oddNumber as always an odd number:

    oddNumber: {
      value({ resolve, listenTo, lastSet }) {
        let lastOddNumber = 5;
        
        resolve(lastOddNumber);
        
        listenTo(lastSet, val => {
          if (val % 2 === 1) {
            lastOddNumber = +val;
          }

          resolve(lastOddNumber);
        });
      }
    }

This doesn't work because, the resolver will only dispatch an event if the underlying value changes:

can-simple-observable/resolver/resolver.js

Line 109 in 42a2b69

if(this.value !== this.lastValue) {

Add key-observable from can-stache

Copy can-stache/src/key-observable.js into this package as the key/ module.

key-observable doesn’t have any tests in can-stache; what should be tested?

resolve called after teardown

For Resolver, we should barf if resolve is called after teardown. Something went wrong.

PROPOSAL: Allow retention of bindings on a read if only values directly on the observable are read

I'd like to retain "active" behavior on getters and async getters that only read values directly on their observable. For example:

const SaltShaker = DefineMap.extend({
	saltCount: {
		value({listenTo, resolve}){
			var saltCount = resolve(0);
			listenTo("fill", ()=>{
				resolve(saltCount = 2);
			});
			listenTo("shake", ()=>{
				resolve(--saltCount);
			});
		}
	},
	fill: function(){
		this.dispatch("fill");
	},
	shake: function(){
		let hadSalt = this.saltCount;
		this.dispatch("shake");
		return hadSalt ? "salt" : null;
	},
	get empty() {
		return ! this.saltCount;
	}
});

As saltCount is only listening on an instance of saltShaker, we can leave it bound once someone reads this.saltCount.

The following should work:

const saltShaker = new SaltShaker();

// when read, we notice that the observation is only listening on `saltShaker`:
saltShaker.saltCount;

// Now that saltCount is active, everything works:
saltShaker.fill();  

console.log( saltShaker.shake() ) //-> "salt"
console.log( saltShaker.shake() ) //-> "salt"  
console.log( saltShaker.shake() ) //-> null   

console.log( saltShaker.empty )   //-> true

I think this would be REALLY nice for getters and async getters:

var VM = DefineMap.extend({
  todoId: "number",
  get todoPromise(){
    return Todo.get({id: this.todoId})
  },
  todo: {
    get(lastSet, resolve){
       todoPromise.then(resolve);
    }
  }
});

var vm = new VM({todoId: 5});

vm.todo //-> undefined
setTimeout(function(){
  vm.todo //-> {todo}
},10000)

Obviously, there would still be corner cases like in saltShaker above. But overall, I think these sorts of behaviors would act more like people suspect.

Thoughts?

Set value on SetterObservable when it's set

In migrating one of our applications to Can 4, I've encountered what appears to be a pretty low-level problem in SetterObservable: specifically, when you call its setter, it never actually updates its value property. I assume this is because it's expected that the observation handler will be used to retrieve the value, but when can-bind calls the setter in updateValue (args.observable will be a SetterObservable in the case where value that's changing is bound to a converter), it then immediately calls the getter on the same observable.

This would be fine, except that because bound is true, the getter (implemented in get-set.js) skips using the observation function and returns this.value directly, which returns whatever the parent value was at the time the binding was set up.

This has a few negative side effects when using two-way binding through a converter:

A confusing semaphore warning is written out to the console because the updateValue function referenced above will cycle multiple times trying to get the parent and child values to agree (even though they already do; it's simply looking at an old snapshot of the parent value to do the comparison), which involves overwriting the child value with the original value of the parent, which will basically always be wrong
The issue that led to me debugging this problem was that my child value was being set first to the expected value, then to whatever the parent value was when the UI was created, then back to the correct value, which was causing unexpected behavior in my application.

I've created a jsbin that reproduces my binding scenario and demonstrates the warning: https://jsbin.com/kevolovonu/4/edit?html,js,console,output

I was unable to get it to reproduce the multiple sets, but I think the warning is probably sufficient to demonstrate that there's a problem here. The solution I found was to add this.value = to the beginning of SetterObservable.prototype.set.

An in-range update of can-event-queue is breaking the build 🚨

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency can-event-queue was updated from `1.1.7` to `1.1.8`.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

can-event-queue is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 4 commits ahead by 4, behind by 1.

86c7082 1.1.8
ad72c04 Update version number
c804191 Merge pull request #34 from canjs/fix-instance-type
d67d7f0 Fix instance typo

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Should implement can.hasKey

I think SimpleObservable should delegate canReflect.hasKey to its data:

var Data = DefineMap.extend({
  foo: "string"
});

var data = new Data();

var obs = new SimpleObservable(data);

canReflect.hasKey(data, "foo"); // -> true
canReflect.hasKey(obs, "foo"); // -> false, should be true

Without this, warnings are shown in {{#each}} loops even for properties that are defined.

const Person = DefineMap.extend({
    title: "string",
    first: "string",
    last: "string"
});

const People = DefineList.extend({
    "#": Person
});

Component.extend({
    tag: "my-app",

    view: `
        {{# each(people) }}
            {{first}} {{last}}
        {{/ each }} 
    `,

    ViewModel: {
        people: {
            Type: People,
            default() {
                return [
                    { first: "Emmet", last: "Brickowoski" },
                    { first: "Wyldstyle" },
                    { last:"Business" }
                ];
            }
        }
    }
});

MyAppView:2: Unable to find key "last".

MyAppView:2: Unable to find key "first".

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Should unbound ResolverObservables return their _value if it exists

Going through one of our examples, I was confused by the behavior of a ResolverObservable that calls resolve synchronously like this:

    prop: String,
    count: {
      value({ listenTo, resolve }) {
        let count = resolve(0); // synchronously calling resolve
        listenTo("prop", () => resolve(++count));
      }
    }

For properties like this, if they are bound and then unbound, they no longer retain their value:

const obs = new Obs();

obs.listenTo("count", ({ value }) => {
  console.log(`count changed to ${value}`);  // -> "count changed to 1"
});

obs.prop = "Hi";

obs.stopListening();

console.log(`count: ${obs.count}`); // -> "count: 0"

This happens because when the property is read after it is no longer bound, the value function is called again and the _value is set to the synchronously resolved value: