Hi there - I see that reader/reader.js was removed in version 3.3.0 - since this is breaking backwrads compatibility, this should have a 4.0.0 release.

☝️ 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.

Your Greenkeeper Bot 🌴

related: canjs/can-view-scope#18

The dependency can-reflect was updated from 1.17.9 to 1.17.10.

🚨 View failing branch.

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

can-reflect 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.

Your Greenkeeper Bot 🌴

It's annoying we always have to convert everything to native promises.

This should happen in reader: https://github.com/canjs/can-observation/blob/master/reader/reader.js#L206

updateChildrenAndSelf attempts to flush a pending update to ensure the returned value is up to date.

I have noticed this failing where observation is a ResolverObservable (from can-simple-observable/resolver/resolver) because it defines an update function, but does not have a deriveQueue property.

For Observation itself, that property is simply aliasing canQueues.deriveQueue.
Wouldn't it be safe to simply also add it to ResolverObservable ?

Moreover; shouldn't it - for both these types - actually be a property of their protoype rather than a per-instance property?

The dependency can-observation-recorder was updated from 1.3.0 to 1.3.1.

🚨 View failing branch.

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

can-observation-recorder 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.

Your Greenkeeper Bot 🌴

The existence of the cssify transform breaks Browserify usage even though can-observation doesn't use css.

This can probably work with CIDStore. This will mean we don't need CIDs for everything.

Related to canjs/can-stache#213

The devDependency can-cid was updated from 1.3.0 to 1.3.1.

🚨 View failing branch.

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

can-cid is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 3.3.2 of can-util just got published.

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

As can-util is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 3.1.1 of can-util just got published.

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

As can-util is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

The dependency can-log was updated from 1.0.0 to 1.0.1.

🚨 View failing branch.

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

can-log 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.

Your Greenkeeper Bot 🌴

A way to execute an obsvervation, asynchronously, via external start/stop methods.

var obs = new Observation();
obs.startDeferred();
obs.stopDeferred();

Version 3.1.1 of can-event just got published.

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

As can-event is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 1.2.0 of can-define just got published.

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

As can-define is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Maps have special rules for writing properties with dots in the their names.

I think this needs to be handled here: https://github.com/canjs/can-observation/blob/master/reader/reader.js#L196

so that it does something like this

if (prop.indexOf('.') === -1) {
        base.attr(prop, newVal);
} else {
        base.attr({ [prop]: newVal });
}

Version 3.0.6 of can-map just got published.

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

As can-map is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 1.2.0 of steal-tools just got published.

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

As steal-tools is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 1.3.0 of steal just got published.

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

As steal is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Related to canjs/can-connect-feathers#50

This error message should explain how to fix this.

can-observation-stack

var observationStack = require("can-observation-stack");

var observation = new Observation();

observationStack.push(observation);

// do stuff ....
observationStack.add( x, "event" );
// ....

observationStack.pop();

observation.updateBindings()

An observation would need something like:

{
  // can have traps if the stack is available
  traps: [{obj, event, name}]
  //
  newObserved: Object<name, {obj,event}>
}

Another alternative is that .pop() returns the newObserved object:

var observationStack = require("can-observation-stack");

var observation = new Observation();

observationStack.push(observation);

// do stuff ....
observationStack.add( x, "event" );
// ....

observation.updateBindings( observationStack.pop() )

It is possible for an observation to be left on the observationStack here, for instance if a compute throws:

var c = compute(function(){
    throw new Error('oh noes!');
});

try {
    c.bind('change', function(){});
} catch(e) {
    Observation.isRecording(); // !!false
}

This can cause strange behavior because all computes will act as if they are bound. For example, in the code below resolve will be defined in the asynchronous getter for foo even though nothing is binding on foo:

var M = CanMap.extend({
    define: {
        foo: {
            get: function(set, resolve) {
                if (resolve) {
                    resolve('bar');
                }
            }
        }
    }
});

var m = new M();

m.attr('foo'); // 'bar'

We should consider warning people when this happens so that they can either:

1. handle thrown errors within their computes
2. use something like compute.safe(function(){...}) which we could provide to wrap the function call in a try/catch

We can tell if this happens by polling Observation.isRecording() with a setTimeout. If it is ever true, it means that something was not popped off the stack.

The tests for can-event.sync are calling async() when they complete. Since this changes the default event behavior, it breaks other tests running in canjs/canjs.

Right now you can use can-reflect to get the value of an observation, but it’d be nice if there was a more simple API for doing that. Related, some observables build on top of can-observation and make it possible to set values; a consistent, friendly API for both getting and setting values would be nice.

Two options stick out to me:

1. Document get() and suggest that other observables implement a set() method. That would look something like:

import Observation from "can-observation";
import keyObservable from "can-simple-observable/key/key";

const observation = new Observation(() => 15);
observation.get(); // -> 15

const observable = keyObservable(/* ... */);
observable.set(22);
observable.get(); // -> 22

2. Create a configurable value property on observations:

import Observation from "can-observation";
import keyObservable from "can-simple-observable/key/key";

const observation = new Observation(() => 15);
observation.value; // -> 15

const observable = keyObservable(/* ... */);
observable.value = 22;
observable.value; // -> 22

I think we should create a can-observation-stack that exports:

.stack
.add()
.trap()
.trapsCount()
.ignore()

This will expose the truly stateful part of can-observation, allowing different can-observation versions. This is important because can-observation changes a decent amount, and it's very hard to make those changes and get the right version into all projects that use can-observation.

can-observation-stack would be much less likely to change.

Playing on the theme that this library is about manipulating a stack of observations.

• module: can-observation
• ObserveInfo.observe(obj, event) -> Observation.add(obj, event)
• ObserveInfo.observes(observes) -> Observation.addAll(observations)
• ObserveInfo.notObserve(fn) -> Observation.ignore(fn)
• Keep .trap() named the same (can't think of a better name here).

The dependency can-key-tree was updated from 1.2.0 to 1.2.1.

🚨 View failing branch.

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

can-key-tree 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.

Your Greenkeeper Bot 🌴

Version 3.5.0 of can-event just got published.

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

can-event is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

From canjs/can-connect#109

Something like:

reader.write({}, "foo.bar", "value")

should let people know what's going on instead of throwing a weird error.

Related to: donejs/bitballs#274

To solve the problem where, the reads that need to be observed are not encapsulated in a function calls.

This will probably require changing observation to allow not providing a function as the first argument:

var observation = new Observation(null, null, function(newVal, oldVal, batchNum){
    console.log("callback", newVal, oldVal, batchNum);
    this.reRender()
})

So that we can observe the operation asynchronously and update in some callback

  componentWillUpdate() {
    observation.pushToStack()
  }
  componentDidUpdate() {
    observation.popFromStack()
  }

Version 3.0.7 of can-compute just got published.

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

As can-compute is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

The dependency can-queues was updated from 1.2.1 to 1.2.2.

🚨 View failing branch.

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

can-queues 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.

Your Greenkeeper Bot 🌴

Similar to async computes, we need some way of creating Observations that can set their values asynchronously.

This would allow us to replace uses of compute.async with Observations and fully support canjs/can-define#149.

https://github.com/canjs/can-observation/blob/master/reader/reader.js#L227
https://github.com/canjs/can-observation/blob/master/reader/reader.js#L233

In both of the above cases, if an error occurs during dispatch, there is no error reported on the console; effectively swallowing the error and potentially leaving the application in an error state.

tldr; Observations created inside other observations should always be entered in the queue after the outer observation. If the outer observation is updated, the child observation should be "stopped" (all handlers unbound and stops listening on its dependencies).

This might eliminate one of the core abilities of nodeLists - the need to recursively unbinding child nodelists!

Background

Take some example stache code like:

{{#if show}}
    <div>{{foo}}</div>
{{/if}}

This gets compiled into the following pseudo observations:

First, an ifBlock with a nested LOGIC block. The LOGIC observation is created
so ifBlock is not rerun over and over if show were to change from 1 to 2 to 3, etc.

var ifBlock = new Observation( () => {
    var LOGIC = new Observation(() => { return !!vm.show })
    
    if(LOGIC.get()) {
        return  options.fn()
    } else {
        return options.inverse();
    }
})

Second, options.fn (and options.inverse) are compiled to something like:

option.fn = function(){
    
    foo = new Observation(() => vm.foo , {canRecordObservation: false});
    return frag("<div/>", live.text(textNode, foo))
}

Note the canRecordObservation on the foo observation. This is used to prevent ifBlock from re-running if foo changes. If foo changes, live.text handles updating the DOM itself. There's no need to rerun ifBlock.

Proposal

The idea is to:

1. make an observation see any observables created within its function and to be able to tear them down automatically when the function returns.
2. schedule any child observations "after" the parent observation, allowing the parent to run first.

In the example above, if ifBlock were to re-run its function, both LOGIC and foo should be torn down.

By torn down we mean all activity should stop. Any handlers listening to those observables should be removed (watch out for handlers bound with .listenTo()). Also those observables should not be binding on their dependencies. Currently, I believe can-event-queues/value supports calling .off() without arguments to tear down any handlers. This should probably be formalized, possibly as a canReflect.stop() (which could also work for Map and List types).

Finally, the child-parent relationship needs to be established. I think part of this can happen with expansion of can-observation-recorder. An observation record could contain a set of createdDependencies:

createdDependencies: new Set()

I think child observables can register themselves with:

ObservationRecorder.created( observable )

When can-observation updates its value, it can go through createdDependencies and call canReflect.stop(observable) on each observable.

Other

• As observation's will take on their "parent's" priority + 1, Infinity + 1 is still Infinity. This might mean resuming the default priority of 0.

See canjs/can-cid#6.

Version 1.0.17 of can-define just got published.

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

As can-define is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

@phillipskevin commented on Fri Mar 10 2017

@phillipskevin commented on Fri Mar 10 2017

console.log breaks IE9 if the console is not open.

https://github.com/canjs/can-observation/blob/master/reader/reader.js#L284

Should detect a promise, then use then to get the value inside. Application: http://jsbin.com/zepaluq/1/edit?js,output

The dependency can-event-queue was updated from 1.1.5 to 1.1.6.

🚨 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.

Your Greenkeeper Bot 🌴

Because the namespace test was changed to look for err.message, it will throw if run with Steal 0.16 (like in the canjs test suite).

Version 3.2.0 of can-compute just got published.

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

As can-compute is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

If there's a computeA that depends on another computeB. If computeB has a dependency change, but comptueA is read, it's possible that computeA will not provide the correct value.

The fix will be making sure that any child compute is not also ready to be updated. If it is, we will have to update it, possibly notify any parents.

Or at least, somehow be able to tell that a change has happened ... and update the parent chain.