Skip to content
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

Enable modification of existing behavior chains #291

Open
nlundquist opened this issue May 10, 2017 · 9 comments
Open

Enable modification of existing behavior chains #291

nlundquist opened this issue May 10, 2017 · 9 comments

Comments

@nlundquist
Copy link
Contributor

nlundquist commented May 10, 2017

Goals:

  • allow modification of existing can-connect behavior chains (via insertion and replacement)

API:

  • newBehaviour.insertAfter(existingBehaviour, behaviourChain) where existingBehaviour is a 'behaviorName' string or behaviour mixin instance matching an existing behaviour in the prototype chain. .insertAfter returns a new connection with the modification made.
    eg.
import superMap from 'can-connect/can/super-map/';
import newBehaviour from './custom-behaviour/';
var connection = superMap(...);
connection = newBehaviour.insertAfter('data/callbacks', newBehaviour);
  • newBehaviour.replace(existingBehaviour, behaviourChain) where existingBehaviour is a 'behaviorName' string or behaviour mixin instance matching an existing behaviour in the prototype chain. .replace returns a new connection with the modification made.
    eg.
import superMap from 'can-connect/can/super-map/';
import newBehaviour from './custom-behaviour/';
import dataCallbacks from 'can-connect/data/callbacks/';
var connection = superMap(...);
connection = newBehaviour.replace(dataCallbacks, newBehaviour);
@nlundquist nlundquist changed the title enable insertion of new behaviors into existing behavior chain enable modification of existing behavior chains May 10, 2017
@matthewp
Copy link
Contributor

This feels wrong to me, you should really be creating new connections rather than modifying an existing one. What is the use case to have a connection that gets modified later?

@nlundquist
Copy link
Contributor Author

nlundquist commented May 10, 2017

@matthewp my use case was the ability to use the predefined behaviour chain of can-connect/can/super-map with a replacement or additional behaviour without having to redefine the entire chain. However this could be accomplished by exposing the list of behaviours attached by superMap, creating a clone of superMap and then modifying the now-exposed list of behaviours directly.

Perhaps @justinbmeyer had another use case in mind where that might not be an acceptable solution?

@justinbmeyer
Copy link
Contributor

@matthewcp yes, people asked for mixins that could be added to an existing connection. This would aid in that.

@nlundquist
Copy link
Contributor Author

thanks for the clarification

@matthewp
Copy link
Contributor

@justinbmeyer I understand that people are asking for it. They are asking for it because creating your own connections is too hard. The solution is make creating connections not hard any more, not add helper methods so people can use superMap and insert stuff in the middle.

@justinbmeyer
Copy link
Contributor

justinbmeyer commented May 25, 2017 via email

@justinbmeyer
Copy link
Contributor

@matthewp (now that I'm back to my computer, a more thoughtful response)

I think I'm acknowledging that creating even a custom base connection would be rather difficult even with can-validate-interface. A basic CanJS connection looks like:

var connection = canMap( constructor( dataUrl( baseBehavior(options) ) ) );

base-map would look like:

var connection = callbacksOnce( realTime( dataParse( dataCallbacks( constructorStore( canRef( canMap( constructor( dataUrl( baseBehavior(options) ) ) ) ) ) ) ) ) );

The solution is make creating connections not hard any more, not add helper methods so people can use superMap and insert stuff in the middle.

The interface stuff and documentation improvements are designed to directly help making piece-by-piece connections. We are also open to other suggestions that would improve this specifically (I'm not aware of alternatives that don't break existing APIs). Even if there are other good suggestions, it doesn't mean this isn't a valid and useful suggestion. This isn't an either-or situation. It's a yes-and.

Fortunately, this can make creating your own connections easy. I can create a "simpleMap" behavior that makes sure canMap, constructor, and dataUrl are all added like:

var someBaseConnection = base({ ... });
var mapConnection = addSimpleMap( someBaseConnection )

If someone wants real-time, it can add constructorStore, realTime, callbacksOnce like:

var connection = addRealTime( mapConnection )

This functionality allows behaviors that mixin several behaviors at once ... collections of behaviors.

@bmomberger-bitovi wanted to make something like real-time automatically add constructorStore and callbacksOnce, but this broke the independence of these behaviors. I think it's important that someone can make a different constructorStore.

This functionality allows mixins that provide a bunch of other behaviors, ensure that the right mixins are present and add them if not.

@matthewp
Copy link
Contributor

matthewp commented Jun 1, 2017

I'm cool with this as long as these "middle level" mixins are created. I believe an end user shouldn't have to choose between high-level things like superMap and super low-level things like data/callbacks. You should be able to build your own connection without knowing about data/callbacks.

What are the mid-level mixins that are needed? I'll create issues for those.

@nlundquist
Copy link
Contributor Author

nlundquist commented Jun 2, 2017

I've added my notes from the most recent contributors meeting where this was discussed to a gist.

@chasenlehara chasenlehara changed the title enable modification of existing behavior chains Enable modification of existing behavior chains Jun 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants