Application structuring - high level component and route glue

[justinbmeyer]

VOTE HERE

There's a need to make the high-level behavior of an application easier to manage. Features might include:

• - progressive loading of modules / components
• - initialization of modules / components
• - animating / switching between pages

Some of this might be accomplishable with #1005. Here's an example:

    can.app({
        "import": function(componentName,callback){
            var script = document.createElement("script");
            script.src = "components/"+componentName.substr(2)+".js";
            script.onload = callback;
            document.body.appendChild(script);
        },
        componentTemplates: {
            "b-contacts": "<b-contacts page='{contactPage}'></b-contacts>",
            "b-contact": "<b-contact contact-id='{contactId}'></b-contact>",
        },
        component: function(){
            return "b-"+can.route.attr("page"); 
        },
        scope: can.route.data,
        animate: function(newContainer, oldContainer, done){
            $(oldContainer).fadeOut();

            $(newContainer).css("position","absolute")
                .css({top: "0px"})
                .width( $(oldContainer).width() )
            .fadeIn("slow",function(){
                done();
                $(newContainer).css({
                    position: "", top: "",width: ""
                });
            });

        },
        element: "main"
    });

[justinbmeyer]

Here's a rough implementation: https://github.com/bitovi/canjsmeetup/blob/master/7_route/can.app.js

[cherifGsoul]

Up vote, this will be great feature

[cherifGsoul]

Why the rough implementation creates script element for each component file? as long as can.Component instantiate itself I think all we need is the custom tag in the DOM and the components can be loaded at once (maybe minified)

[justinbmeyer]

@cherifGsoul I'm not sure what you mean. Please elaborate.

We create script elements for progressive loading. Component might not be loaded into the page.

[cherifGsoul]

Sorry for my limited english, what I mean is components files can be loaded all at once because there's no component instantiation if it's template is not present, what is the goal of the progressive loading in this case?

[justinbmeyer]

I'm still not sure what you mean. Please break down more. Can you give an example?

Sent from my iPhone

On Aug 27, 2014, at 3:59 PM, Mohamed Cherif Bouchelaghem [email protected] wrote:

Sorry for my limited english, what I mean is components files can be loaded all at once because there's no component instantiation if it's template is not present, what is the goal of the progressive loading in this case?

—
Reply to this email directly or view it on GitHub.

[cherifGsoul]

Im talking about the import part because IMO components dont need progressive loading, maybe im wrong because it treats components and other modules loading, I have a little idea that will be shared soon.

[justinbmeyer]

What do you mean by "treats"?

Components, like other modules, can be progressively loaded in larger apps. Say I went from /contacts to /admin. I might want to load the admin component when that happens.

Sent from my iPhone

On Aug 28, 2014, at 9:42 AM, Mohamed Cherif Bouchelaghem [email protected] wrote:

Im talking about the import part because IMO components dont need progressive loading, maybe im wrong because it treats components and other modules loading, I have a little idea that will be shared soon.

—
Reply to this email directly or view it on GitHub.

[cherifGsoul]

"treats" => do the loading action, what I mean, the admin component file can be loaded in this case even if it is not used yet, but its custom tag is not present in the DOM, like this component progressive loading is not very important IMO (just for component case).

[cherifGsoul]

this is a quick example for what I mean even if page component are present they are not instantiate if their templates are not rendred
http://jsbin.com/yuyumu/2/edit
the gist https://gist.github.com/cherifGsoul/645db39ab8e8b24505d9 .

[justinbmeyer]

I get a 404 when I click on your jsbin. I'm still not sure what you are trying to say. If the component's definition is already loaded, yes, progressive loading is not important. But I want to enable apps where this is not the case.

[cherifGsoul]

For 404 is the jsbin behavior when working with route, try it in full window http://jsbin.com/yuyumu/2#! I undertand the need for progressive loading for modules but component.

[justinbmeyer]

It would also be nice to have some of this behavior possible via HTML only:

<can-route pattern=":page" page="home"/>
<can-route pattern="contacts/:id" page="contacts"/>
<my-app>
  <navigation/>
  {{#switch can.route.page}}
    {{case "home"}}
       <h1>Welcome {{name}}</h1>
    {{case "contacts"}}
       <contacts page='{can.route.contactPage}'
                     can-animate-removed="fadeOut" 
                     can-animate-inserted="fadeIn"></contacts>
    {{case "contact"}}
      <contact contact-id='{contactId}' 
                     can-animate-removed="fadeOut" 
                     can-animate-inserted="fadeIn"></contacts>
  {{/switch}}
</my-app>

Things that would have to work:

• - a switch statement that would integrate with the animations to remove an element before inserting it
• - dynamic importing of a component

[cherifGsoul]

@justinbmeyer I like this I wonder if can-route tag will be wrapper for the app or just hidden tag to handle can.route in declarative manner?

[stevenvachon]

Oooo {{#switch}}!

Inspired me to write: http://jsfiddle.net/prometh/c71L3hzn/

[stevenvachon]

@justinbmeyer I don't know if I like the idea of defining routes in the template. Wouldn't this belong in JavaScript, as it's more logic than view? And if it were to be in the template, I'd opt for {{#can-route ":page" "home"}} instead, to avoid <can-route/> from looking like something that is rendered.

[matthewp]

I love the idea of defining routes in templates. I think using attributes to set default values makes it clearer what is happening than by calling the JavaScript function. Also I think this will lead more people into defining their routes in a single place, rather than throughout the application.

[stevenvachon]

@matthewp wouldn't route definitions be better placed in the can.app javascript? It's still in a single place and <can-route/> isn't a visual element.

I'm not against the idea, of course, as it's a matter of opinion, but am curious of why you prefer it template-based.

[matthewp]

Routes don't belong in can.app because they really don't have anything to do with it. You can have an app without any routes at all. What defines an app is its state. Routing is the thing most people find confusing when using CanJS, so we need to make some efforts to simplify it. In my opinion that means removing all of the extraneous APIs (like being able to listen to route changes in Controls) and push towards the "correct" way of using routes. So we need to figure out what will make it easier to understand.

[cherifGsoul]

@matthewp IMO even this wont simplify the route, the main reason is not CanJS but other frameworks where application code has tight coupling to route (like backbone) the new developers may get this quickly but it will be hard for developer who change the framework/library

[stevenvachon]

@matthewp How do routes belong in can.app's template any more than they belong in can.app's javascript? Sure, an app is all state-based and the router simply reflects it interactively in the address bar, but what justifies a change in state is in can.app's javascript (likely a can.compute), not the template. Shouldn't the route definitions be in the same document as that justification?

[cherifGsoul]

@justinbmeyer can you tell me if the will be better if is based with can.view.tag or can.Component?

[justinbmeyer]

<can-route route=":page" page="todos">
   <todos-app>

   </todos-app>
</can-route>

[stevenvachon]

@justinbmeyer doesn't that make canjs a route-based design rather than state-based design? Or is <can-route/> mainly for increasing dev options?

[cherifGsoul]

@justinbmeyer I already did a rough example for this in the jsbin above, if you have some time can you tell me what you think about it? I named it ui-manager

[justinbmeyer]

@cherifGsoul Please remind me to get back to you next week. Busy time for me. Thanks!

@stevenvachon It makes this functionality route-based, but the existing functionality will still be present.

[zkat]

I've been using a <can-router> and <can-router-route> pair of components pretty successfully at a client application, it's been working like a charm :). Also got some great ideas from @imjoshdean for what sorts of extra options for page management they might need.

From the sandbox page:

    <header>header</header>
    <can-router map="{.}">
        <can-router-route href="">
            Hello, world{{punctuation}}
        </can-router-route>
        <can-router-route href=":name">
            Hello, {{name}}{{punctuation}}
        </can-router-route>
    </can-router>
    <footer>footer</footer>

[wclr]

can-router-route is tautological

[stevenvachon]

taut-o-what?

[zkat]

@whitecolor Think of can-router- as a prefix for components that are meant to be children of can-route. It's a pattern I've used in a few other places to namespace elements and specify what parent they belong to -- so I don't consider it a tautology :)

I also think the visual distinction between can-router and can-route is too small so meh.

[justinbmeyer]

I think this is still an unsolved problem. Marking as "future feature" because the exact solution is not specified.

[justinbmeyer]

while I think we need to do something here, this is mostly solved by donejs.