canjs/canjs

We CAN build the impossible! https://codepen.io/justinbmeyer/pen/yEGGoK

Brad Momberger

@bmomberger-bitovi

And also give your DefineMap subclasses names. :)

Nico R.

@nriesco

what do you mean?

Brad Momberger

@bmomberger-bitovi

DefineMap.extend("NameForThisMap", { ... })

Nico R.

@nriesco

otherwise I’m extending the whole DefineMap class for the whole app?

Brad Momberger

@bmomberger-bitovi

no, it just doesn't change the name on the constructor

If you extend a DefineMap without a name, it's still got "DefineMap" as the name

which can make it harder to track down "the definition for ok on DefineMap"

can-component actually generates names for the DefineMap subclass if you pass plain objects (i.e. DefineMap prototypes) in as the viewModel

I'm not saying to do that. I am saying, when you extend a DefineMap, it's good practice to give the extended map a name.

Nico R.

@nriesco

oh, I see you refer to the warning I got, thanks a lot, that shuld definitely make thinks easier to track

Morgan Heimbeck

@Xitstrategies

@justinbmeyer I am just waiting to hear from you on canjs/can-ajax#13 If there is someone who can give me a brief run down or document on what all I need to do to document my pull request change, let me know.

Brad Momberger

@bmomberger-bitovi

@Xitstrategies take a look at https://github.com/canjs/can-ajax/blob/master/can-ajax.js#L33

It should suffice to add xhrFields as a param to the options object, if you can also link to somewhere that explains the format.

Morgan Heimbeck

@Xitstrategies

@bmomberger-bitovi thanks!

Jim O'Harra-Sutton

@Psykoral

Anyone know the new CanJS 3 version of can/map/delegate? https://v2.canjs.com/docs/can.Map.prototype.delegate.html . I'm trying to do essentially the same thing... Give it a Map to watch, and if this particular property changes, do stuff

Brad Momberger

@bmomberger-bitovi

https://github.com/canjs/can-map-delegate

We were shockingly uncreative about some of these package renames

Jim O'Harra-Sutton

@Psykoral

right, but it says it's deprecated

Brad Momberger

@bmomberger-bitovi

All of can-map is deprecated.

Jim O'Harra-Sutton

@Psykoral

uncreative isn't a bad thing by the way, it is what it says it is :)

right, I guess I'm trying to find "whatever is the new way" to watch a Map value change

Brad Momberger

@bmomberger-bitovi

What you're doing with the changed value matters.

Jim O'Harra-Sutton

@Psykoral

I merely want to listen for it to be changed

Brad Momberger

@bmomberger-bitovi

If it's in another Map, using can-map-define or upgrading to can-define/map/map will let you define a getter that listens to that map's changes.

Jim O'Harra-Sutton

@Psykoral

AH ha, there we go... where would I find info on that right there

specifically listening to the value of an item in another map, exactly

Brad Momberger

@bmomberger-bitovi

For can-map-define: https://canjs.com/doc/can-map-define.html

For can-define/map/map (this would require some migration work): https://canjs.com/doc/can-define/map/map.html

Jim O'Harra-Sutton

@Psykoral

I am using can-define/map/map yeah

Brad Momberger

@bmomberger-bitovi

If you want to do this outside of a map's property, you can use can-compute instead: https://canjs.com/doc/can-compute.html

The general idea is pretty much the same between a getter on a defined map or a getter-setter in can-compute: Any other compute or property of a can-map or DefineMap that is read by the getter will cause the value to update when it changes.

Jim O'Harra-Sutton

@Psykoral

I want to have one Map A look at a property of a Super Map,and when that value changes do some things in Map A

Brad Momberger

@bmomberger-bitovi

So if you have a DefineMap A, and a DefineMap B (which could be coming from can-connect/super-map)...

And A.foo is a getter that reads the value of B.bar...

And (this is important) A.foo is bound

Then the getter for A.foo is called every time B.bar is updated.

In practice, that looks like this:

var B = new DefineMap({ bar: "some string" });
var AC = DefineMap.extend({ foo : { get() { return B.bar } } });
var A = new AC();
A.on("foo", function() {});  // <- this is binding.  You don't need to do this if a Stache is reading A.foo

Jim O'Harra-Sutton

@Psykoral

I'm probably not using the "getters" like I should be. Truth be told I'm still figuring out the syntax of the new (to me) DefineMap

Ah OK, let me try that

Brad Momberger

@bmomberger-bitovi

A more generalized form might put B in A as a property:

var B = new DefineMap({ bar: "some string" });
var AC = DefineMap.extend({ b: {}, foo : { get() { return this.b.bar } } });
var A = new AC({ b: B });
A.on("foo", function() {});

This is analogous to A being a view model, and containing B as a data model.

Jim O'Harra-Sutton

@Psykoral

cool, I've got some other errors to dig through but I think that worked

thanks again!

Brad Momberger

@bmomberger-bitovi

You're welcome. Good luck with your other errors.

Jim O'Harra-Sutton

@Psykoral

Do I have to specifically use a setter in order to make the getters "listen and react" to the changed value?

Brad Momberger

@bmomberger-bitovi

No. Setters can be used for translating inputs or other side effects, but they're not strictly necessary. You can have a getter without a setter.

Jim O'Harra-Sutton

@Psykoral

because right now, based on your sample above as reference, I'm just setting B.bar = null and B.bar = 'a thing' and thought that would be enough to make the getters do their updates

Brad Momberger

@bmomberger-bitovi

It should be. Do you see the getter effect happen when you read A.foo directly?

Jim O'Harra-Sutton

@Psykoral

my eqiv of A.foo is in a stache, so no that HTML isn't showing when I change the value of B.bar

Where communities thrive

People

Repo info

Activity