Skip to content
This repository has been archived by the owner on Oct 29, 2019. It is now read-only.

Proposal: Lazy instantiation of components #21

Open
akoenig opened this issue Jul 17, 2015 · 3 comments
Open

Proposal: Lazy instantiation of components #21

akoenig opened this issue Jul 17, 2015 · 3 comments

Comments

@akoenig
Copy link

akoenig commented Jul 17, 2015

It's more of a feature in the ComponentDomParser but I write it down here for the time when we transfer the projects over to the new GitHub organization.

We should find a way to lazy instantiate components when a specific condition is fulfilled. Therefore we can avoid the instantiation of sub-components within a parent component. So instead of doing this:

import {Component} from 'nodeproto';
import SubComponent from 'ma-subcomponent';

class ParentComponent extends Component {
     // yada yada yada yada

    anAction () {
        let subc = new SubComponent();
    }
}

we should find a way to do this in a declarative way, like:

import {Component} from 'nodeproto';

class ParentComponent extends Component {
    // yada yada yada yada

    anAction () {
        this.modalVisible = true;
    }
}
<div data-component="ParentComponent">
     <div data-component="SubComponent" data-component-when="ParentComponent.modalVisible">
        yip yip yip
     </div>
</div>

@Inkdpixels @grebaldi What do you think?

@grebaldi
Copy link
Member

I see your point, but I wouldn't solve this by explicitly addressing the Parent Component with another data-* attribute.

imho we should extend the syntax within data-component instead by some decoratorish/annotationish thing, I would think of:

class ParentComponent {
    constructor() {
        this.mySubComponent = null;
    }
}
<div data-component="ParentComponent">
    <div data-component="@Inject(mySubComponent) @Lazy SubComponent">
    </div>
</div>

@Inject would just set mySubComponent in the ParentComponent, which is implicitly addressed.
@Lazy would maybe create some Proxy, so SubComponent gets instantiated at first call.

... I just realized, that this won't cover the condition thing - but still, imho the ParentComponent should decide that on js side.

EDIT:

This whole concept clearly conflicts with reduct/assembler#8 - we should really think this through. Currently I don't have a solution in mind for addressing everything in a readable manner...

@Inkdpixels
Copy link
Contributor

Just a question for the archives:
Whats the purpose on not instantiating a Component via your ParentComponent?
What are the thoughts/benefits you are aiming for?

To me it seems a bit too complex to solve "dependencies" across Components via the parser/html.
I don't know why, but specifying a certain state(?) of a JS component in your html, or even chaining Components via html feels "meh".

If you are just aiming at having a more decoratorish/annotationish syntax as @grebaldi posted, we should maybe add this in the NodeProto instead. I dont have a proposal at hand for this, but maybe we should talk about this beforehand to clearly map out the benefits/drawbacks on why and where we should integrate this.

@grebaldi
Copy link
Member

Maybe this could be solved by just resolving "Subcomponents" with a seperate instance of componentdomparser as a member of the parent component, that can be invoked under some "runtime" condition... But then we should find a way to share a common component index across components to not loose the benefits of the single point of entry approach -> all this sounds like too quickly growing complexity to me...

I think we should find a clear definition of what a "Subcomponent" could/should be and/or sort out, if there are enough use cases to justify a special treatment of these.

Nevertheless - if there is such a thing as Subcomponents, we definitely need some at least unilateral way to address them or their parents.

EDIT:
@Inkdpixels

To answer at least your first question: It helps to reduce explicit dependencies and therefore encourages more abstraction, since any server side rendering process could wire components together, that do not have to know each other... (that is the reason, I would think of 😄 )

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants