New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lexical semantics for can.Component #1069

Closed
zkat opened this Issue Jun 11, 2014 · 12 comments

Comments

Projects
None yet
5 participants
@zkat
Contributor

zkat commented Jun 11, 2014

can.Component should have lexical semantics for its light dom. Consider this fiddle: http://jsfiddle.net/5D4FK/2/

Lexical semantics would shield the user from internal implementation details of the component. Likewise, they would shield the Component itself from unintended (or even intended) injection from the outside. Conceptually, the user should never know/care about the internal details of a component's shadow dom and interact with it purely through its exposed API (attributes and the light DOM, rendered in the lexical template context).

@zkat zkat added the Bug label Jun 11, 2014

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 11, 2014

Contributor

I think it should be optional. I've found the use of the data/helpers of the parent component in light dom super useful many many times. From the presentation I did today:

<my-app>

    <div>
        {{link "Drivers", "drivers"}}
        {{link "DMVs", "dmvs"}}
    </div>

    {{#if showDMVS}}
        <dmvs></dmvs>
    {{/if}}
    {{#if showDrivers}}
        <drivers></drivers>
    {{/if}}
</my-app>

link, showDMVS, showDrivers are all provided by <my-app>

Contributor

justinbmeyer commented Jun 11, 2014

I think it should be optional. I've found the use of the data/helpers of the parent component in light dom super useful many many times. From the presentation I did today:

<my-app>

    <div>
        {{link "Drivers", "drivers"}}
        {{link "DMVs", "dmvs"}}
    </div>

    {{#if showDMVS}}
        <dmvs></dmvs>
    {{/if}}
    {{#if showDrivers}}
        <drivers></drivers>
    {{/if}}
</my-app>

link, showDMVS, showDrivers are all provided by <my-app>

@justinbmeyer justinbmeyer removed the Bug label Jun 11, 2014

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 11, 2014

Contributor

Removed the bug label. This might be a feature. The switch is as easy as changing:

https://github.com/bitovi/canjs/blob/master/component/component.js#L291

and maybe

https://github.com/bitovi/canjs/blob/master/component/component.js#L306

To use hookupOptions.scope instead of renderedScope/rendererOptions.scope. But I still think this should be optional. A component might want to provide the light DOM helpers/data and callback methods.

Contributor

justinbmeyer commented Jun 11, 2014

Removed the bug label. This might be a feature. The switch is as easy as changing:

https://github.com/bitovi/canjs/blob/master/component/component.js#L291

and maybe

https://github.com/bitovi/canjs/blob/master/component/component.js#L306

To use hookupOptions.scope instead of renderedScope/rendererOptions.scope. But I still think this should be optional. A component might want to provide the light DOM helpers/data and callback methods.

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Jun 11, 2014

Contributor

I think making it optional is reasonable, but I think defaulting to lexical behavior is much better for writing nice, modular code and surprising users less in the long run, assuming they are used to lexical semantics for variables (like JavaScript's defaults). Consider how confusing dynamic bindings such as this end up being, in practice for users. There is, of course, a place for stuff like that but I think it's important to make the general case "safe", and encourage users to use component features more when exposing stuff like in your example.

Contributor

zkat commented Jun 11, 2014

I think making it optional is reasonable, but I think defaulting to lexical behavior is much better for writing nice, modular code and surprising users less in the long run, assuming they are used to lexical semantics for variables (like JavaScript's defaults). Consider how confusing dynamic bindings such as this end up being, in practice for users. There is, of course, a place for stuff like that but I think it's important to make the general case "safe", and encourage users to use component features more when exposing stuff like in your example.

@thomblake

This comment has been minimized.

Show comment
Hide comment
@thomblake

thomblake Jun 11, 2014

Yeah, this is more intuitive for folks who live in JS, which I would assume is the target audience.

Yeah, this is more intuitive for folks who live in JS, which I would assume is the target audience.

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 11, 2014

Contributor

The target audience for the light DOM is less JS developers and more HTML devs / Designers.

Contributor

justinbmeyer commented Jun 11, 2014

The target audience for the light DOM is less JS developers and more HTML devs / Designers.

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Jun 11, 2014

Contributor

leaking {{bindings}} is much more prone to surprises, and it's unfriendly to designers who just want to use a component without having to know its internals. With the current behavior, designers now have to know about the internal details of the viewmodel in order to not accidentally capture values in it.

Contributor

zkat commented Jun 11, 2014

leaking {{bindings}} is much more prone to surprises, and it's unfriendly to designers who just want to use a component without having to know its internals. With the current behavior, designers now have to know about the internal details of the viewmodel in order to not accidentally capture values in it.

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Jun 13, 2014

Contributor

The PR is using dynamicContentBindings as a flag to toggle between lexical and dynamic binding. Anyone have better ideas?

Contributor

zkat commented Jun 13, 2014

The PR is using dynamicContentBindings as a flag to toggle between lexical and dynamic binding. Anyone have better ideas?

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 13, 2014

Contributor

I don't have a better one, but I do have lots of random thoughts:

The "content" is the "light" or "user" content/DOM.

I'm afraid bindings is an overly used word in CanJS (and jQuery) that has other meanings. Dynamic is kinda vague.

Maybe addScopeToUserContent or addScopeToLightContent.

I don't like this because "scope" is over used. If we change scope to viewModel in 3.0, and we wanted to be very explicit: addViewModelToLightContentScope. A bit wordy.

Contributor

justinbmeyer commented Jun 13, 2014

I don't have a better one, but I do have lots of random thoughts:

The "content" is the "light" or "user" content/DOM.

I'm afraid bindings is an overly used word in CanJS (and jQuery) that has other meanings. Dynamic is kinda vague.

Maybe addScopeToUserContent or addScopeToLightContent.

I don't like this because "scope" is over used. If we change scope to viewModel in 3.0, and we wanted to be very explicit: addViewModelToLightContentScope. A bit wordy.

@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Jun 18, 2014

Contributor

Did we decide on a name for the property?

Contributor

matthewp commented Jun 18, 2014

Did we decide on a name for the property?

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 18, 2014

Contributor

leakScope

Justin Meyer
847-924-6039

On Wed, Jun 18, 2014 at 10:04 AM, Matthew Phillips <notifications@github.com

wrote:

Did we decide on a name for the property?


Reply to this email directly or view it on GitHub
#1069 (comment).

Contributor

justinbmeyer commented Jun 18, 2014

leakScope

Justin Meyer
847-924-6039

On Wed, Jun 18, 2014 at 10:04 AM, Matthew Phillips <notifications@github.com

wrote:

Did we decide on a name for the property?


Reply to this email directly or view it on GitHub
#1069 (comment).

@daffl

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Feb 18, 2015

Contributor

Closed via #1429

Contributor

daffl commented Feb 18, 2015

Closed via #1429

@daffl daffl closed this Feb 19, 2015

@daffl daffl removed the fixed in branch label Feb 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment