These are chat archives for canjs/canjs

7th
Jun 2018
Chasen Le Hara
@chasenlehara
Jun 07 2018 18:12
@roemhildtg That seems like a valid, doable use case… mind filing an issue?
Dovid Bleier
@dbleier
Jun 07 2018 18:42
I am trying to extend an existing model to use with a different end point for another component in the app. However the way I am doing it seems to overwrite the end point of the original model as well, thus returning the wrong data on the original component.
here is the code for the extended model
import Unit from './unit';

const UnitQuery = Unit.extend();
UnitQuery.connection.url.getListData = "GET /admin_console/queryUnits/1";
export default UnitQuery;
where am I going wrong?
zhan ishzhanov
@janat08
Jun 07 2018 19:10
Can any1 reassure me that stach is fast
Or as fast as react
Kevin Phillips
@phillipskevin
Jun 07 2018 19:14
@justinbmeyer gave some comparison :point_up: May 30, 2018 9:23 AM
Chasen Le Hara
@chasenlehara
Jun 07 2018 19:57
@dbleier Is the connection the same object? I would think that’s what needs to be different between the two models.
It might make more sense to have a function that returns a new connection, that you can pass the URL (or whatever other options that might be different between the models).
@janat08 Performance is one of those things that is so dependent on the specific code, browsers at the time, etc.
I think it’s tough to say that X is always faster than Y… it usually all depends.
Chasen Le Hara
@chasenlehara
Jun 07 2018 20:02
That said… this part of the DoneJS site explains why CanJS is typically more performant than React when dealing with lots of DOM nodes & updates: https://donejs.com/Features.html#minimal-dom-updates
Both the CanJS & React versions are out of date on that page and in the JS Bin: https://output.jsbin.com/zigovul/7
…but I think the overall principle stays the same: when a CanJS observable updates, it can change just a specific part of the DOM, vs. needing a re-render & virtual DOM diff in React.
Dovid Bleier
@dbleier
Jun 07 2018 20:15
@chasenlehara seems that the connection is the same object, I thought .extend() would clone the object, but I guess not
I got this idea from a previous conversation with you. So I guess I am a bit unclear on the value of extending my model.
I don't want to have to pass the URL. The app shouldn't know the details of the connection
Chasen Le Hara
@chasenlehara
Jun 07 2018 20:30
Sorry my answer wasn’t super clear—let me back up a bit.
In your unit.js file, you’re setting up Unit and, I’m assuming, assigning Unit.connection there
When you make UnitQuery, it’ll have the same properties assigned to Unit, which includes connection
So Unit.connection === UnitQuery.connection… they’re the same object in memory
But you can assign something different to UnitQuery.connection
Chasen Le Hara
@chasenlehara
Jun 07 2018 20:36
There’s a couple ways you could write that code; one way would be a helper function that creates the connection, e.g. function createConnection(url) { return connect({ ... options, like url }) }
Then you would use that for each one, so Unit.connection = createConnection( ... ) and UnitQuery.connection = createConnection( ... )
Then the connection objects would be different (and have different options), but you would still use them the same way (e.g. you don’t have to pass the URL around, the model is already configured with it)
Let me know if that makes a little more sense; if not, happy to write it out a little more! 😀
Dovid Bleier
@dbleier
Jun 07 2018 20:44
yeah, I think so
thanks
Chasen Le Hara
@chasenlehara
Jun 07 2018 20:55
👍