These are chat archives for canjs/canjs
@justinbmeyer /rant The CC recipe is nice, and I like how you had included the form value bindings. Those were not something that was apparent to me for a long time while using CanJs and I had to do a bunch of workarounds to replicate that functionality. I worked on a project with CanJs and socket.io and I was not made aware that the can.model had any websocket functionality. I feel like the canjs api documentation just does not spell it out, and I had just heard of this implementation in the chat with you and @frank-dspeed . I would like more recipes to focus on explaining models a bit more. As well as explaining how to do proper session handling, I kind of understood it from BitBalls, but I had some workarounds. Also, It would be nice to create recipes for standard ui widgets like datatables and modals and alerts. I wrote my own reusable component https://pastebin.com/QVeGyHVg that you can pass your own model to it and your own table body template with this init code https://pastebin.com/Uxk2RWg2 and this stache template http://prntscr.com/fmnmhp . I was using laravel as a backend for it and it worked out so nice, it had infinte scrolling and pagination and a jquery-floathead plugin attached to it. ( I would like to know what is the best way that you guys think that I should publish it, so it is not overwhelmed by a huge php framework. ). I also did not initialiy understand that properties of an object could not be observed if they did not exist. So I did not know that my models had to be set up like this http://prntscr.com/fmnnp2 so that they could be properly observed in the view like this http://prntscr.com/fmnnig . I just think in all honesty the api is a bit hard to understand for it is very vast and uncanny, especially to people that are new to front end MVC/MVVM frameworks. I just think that certain things are just not so apparent. I've been wanting to put all these issues that I came across into a new smaller more documented version of BitBalls where I had to solve those newbie pitfalls. I know I've said this before, but these things that I am mentioning to the developers of CanJs are second nature. You guys understand the whole models api but to a newbie http://prntscr.com/fmnp1n that alone is hard enough to get a grip on directly from the API docs. It is hard to understand where it starts and ends. I am a person that learns from looking at code more than watching a video. Like most CanJs developers are making SPA websites that have complex interactivity. These projects that I have used CanJs for have almost been direct BitBalls clones in theory, of having a login system and forms that put data in a database and datatables and some sort of file mangement. I would like to come up with a plan to focus on making a nice boiler plate to accomplish that.
Also @frank-dspeed I know you mentioned that "You have to learn the CanJs way of doing it", I would like to have that "way" made into a boilerplate that is common knowledge to entry level CanJs developers.
I am not exactly sure on how accomplish this boilerplate of knowledge but I am free to spit ball ideas.
Could someone explain why we pass
viewModel in add, but
scope in remove here:
why not to use vm in both cases ?
scopeis still there for compatibility reasons is the same as viewModel https://github.com/canjs/can-component/blob/master/can-component.js#L220
can-modeldoesn't have real-time, that was added w/
@justinbmeyer Oh.. that makes a lot of sense. Although I was able to achieve somthing similar within the view-model the performance only got worse.. I'll come back with the findings.
Meanwhile, going back again to my question on how to deal with the returned promise from the Model.getList() method in the use case I've presented your suggestion is applicable - getting the promise only when I need to resolve it - but I'm facing other scenarios where I need to get that promise and "move it around" until later it will be resolved. The data should be fetched only when something tries to resolve the reference to that promise. But as explained before the Promise is resolved as soon as
return Model.getList() gets called. My question here is: Would it possible to wrap this thenable in a new promise to avoid that?