These are chat archives for canjs/canjs

9th
Jul 2018
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 10:01
@qantourisc I dont see what do you mean?
@qantourisc
dMap.dMap = new DefineMap(//props);
Viktor Busko
@Lighttree
Jul 09 2018 10:41

Guys, I'm calling list of such entities:

const Foo = DefineMap.extend({ seal: false }, {
    id: 'number',
    barId: 'number',
    bar: {
        Type: Bar,
        get(last, resolve) {
            Bar.get({
                id: this.barId
            }).then(resolve);
        }
    }
});

Each Foo has reference to Bar and makes separate call for Bar.
This generates many request, right now sequence of requests is...

https://localhost:3000/api/v1/bar
https://localhost:3000/api/v1/bar/10001
https://localhost:3000/api/v1/bar/10002
https://localhost:3000/api/v1/bar/10003

I can do Bar.getList() earlier and ideally this Bar.get(this.barId) should not happen and wait for data from Bar.getList().

Is it possible to achieve using some behavior ? So my requests list will be like

https://localhost:3000/api/v1/bar

(The only way that I see right now is wrap all application into this Bar.getList() call and render it only after this)

Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 11:22
@Lighttree does the response of the API contain the bar object?
qantourisc
@qantourisc
Jul 09 2018 11:34
@cherifGsoul so I should use = and not assign ?
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 12:14
@qantourisc It depends on your use case, usually = works fine for most of cases
CODE-REaD
@CODE-REaD
Jul 09 2018 13:46
TWIMC, <script src="https://unpkg.com/can/dist/global/can.js"></script> still fails (see :point_up: July 7, 2018 12:43 PM). I suspect a pointer was omitted in the last updates. FWIW I found another workaround: <script src="https://unpkg.com/can@4/dist/global/can.all.js"></script>.
Kevin Phillips
@phillipskevin
Jul 09 2018 14:28
@CODE-REaD the build changed a lot for 5.0
to allow for the module build (.mjs)
the "global" builds that are available now are the core.js and ecosystem.js builds: https://github.com/canjs/canjs/blob/67322c82e84a2f8ff5c469da2dd24d236b456b63/build.js#L66-L73
Kevin Phillips
@phillipskevin
Jul 09 2018 14:34
https://unpkg.com/can@4/dist/global/can.js -> https://unpkg.com/can@5/dist/global/core.js
https://unpkg.com/can@4/dist/global/can.all.js -> https://unpkg.com/can@5/dist/global/ecosystem.js
Julian
@pYr0x
Jul 09 2018 14:52
:point_up: 8. Juli 2018 13:50 hey kevin... do i ask you this question before?
Kevin Phillips
@phillipskevin
Jul 09 2018 14:53
hmm, I'm not sure if you've asked before
I think it should work, let me try it
Kevin Phillips
@phillipskevin
Jul 09 2018 14:59
it doesn't work :frowning:
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 14:59
@pYr0x the solutions I suggested dosent work for your case?
Julian
@pYr0x
Jul 09 2018 15:01
@cherifGsoul i want to set it like this vm:cc.height:raw="100"
inside a stache file
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:01
Ok
Julian
@pYr0x
Jul 09 2018 15:01
with can.bind i have to bind it outside of a stache file
@phillipskevin do you think this can be done with little affort in stache bindings?
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:02
Yeah it was suggested as a temporary solution
Julian
@pYr0x
Jul 09 2018 15:02
;)
Kevin Phillips
@phillipskevin
Jul 09 2018 15:02
I'm not sure @pYr0x
I think canjs/can-stache-bindings#104 might be the solution
Viktor Busko
@Lighttree
Jul 09 2018 15:34

does the response of the API contain the bar object?

@cherifGsoul yes

Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:37

@Lighttree I think is because of this part:

get(last, resolve) {
            Bar.get({
                id: this.barId
            }).then(resolve);
        }

is invoked for each foo instance

Viktor Busko
@Lighttree
Jul 09 2018 15:38
Well yes I know this :) But I need this Bar info for Foo objects and as far as I know it is Ok way to do this. Or maybe there is another option ?
Basically I was thinking that can able to understand that I'm making full list request and wait for it instead of doing this single items requests :)
but maybe this is too much
I probably missed important note )
I'm using localStorage cache
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:41
If bar object in the response has the same props in Bar type it can be created in Foo type without having the get behavior
Viktor Busko
@Lighttree
Jul 09 2018 15:42
no its like Foo has only barId. And at Model level I'm adding bar field by myself, by this field with get, that you can see.
So the idea was to get full ist of Bars and put them in cache in order to avoid calling bar info for each foo :)
(omg this foo/bar stuff makes things more complicated :))
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:45
But it looks like you have one bar for foo (one to many relationship)
Viktor Busko
@Lighttree
Jul 09 2018 15:46
I'm calling list of Foos. Each Foo has reference to some Bar.
But I can have like thouthands Foo and I know that there is just 10 Bars.
So I was going to call once 10Bars instances put them to cache, so my Foo items won't call 1000 times the same info
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:50
things will be more easy If foo in server response is like this:
{
   id: 1,
   prop: 'qwerty',
   bar {     
    id: 1,
    prop: 'value'
  }
}
Viktor Busko
@Lighttree
Jul 09 2018 15:50

So like... hmm... I'll try to think about something more specific.

Like we have a list of cars. And we know that we have only limited amout of colors. But car object doesn't know which color it is.
So if we request 1000 cars, each entity will go and request info about color. But we know that there are just 5 options.
So the idea is to get all colors just once, so later cars will get this info from cache, without calling color service

things will be more easy If foo in server response is like this:

Thats true, but this is not how its decided to be implemented :)

Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:51
Ah Ok, I understand now
Maybe caching the lookup data first will do the trick
Viktor Busko
@Lighttree
Jul 09 2018 15:56

Yes it is already cached, but as far as I got request for list of "colors" happens the same time as list of "cars" and request for "color" in particular "car" will happen because at this stage there is nothing in cache. And I was thinking that maybe there is behavior that checks like...
if we have request like
https://localhost:3000/api/v1/colors

don't make call
https://localhost:3000/api/v1/colors/10001

Because you will have this info soon.

But there is no such, so its ok :) I think we will be ok with how it works right now.

Actually after this first call this will work as expected, because info cached already )
Mohamed Cherif Bouchelaghem
@cherifGsoul
Jul 09 2018 15:57
@Lighttree Nice
srikkanthsiki
@srikkanthsiki
Jul 09 2018 20:45
hi
srikkanthsiki
@srikkanthsiki
Jul 09 2018 21:14
has any one used react-router with can.Component
does it work
Julian
@pYr0x
Jul 09 2018 22:20
@chasenlehara i got an error with can.value 0=> TypeError: Cannot read property '_bindingState' of undefined
the problem comes up if i remove the x-dashboard-logistics from DOM
it is hard to explain, maybe you have some time and i can show you the code and the problem, maybe we can create a simple example