From d88f4106251feb70146e0202f56419ba34d96c1b Mon Sep 17 00:00:00 2001 From: J Corley Date: Mon, 12 Jun 2017 12:04:06 -0500 Subject: [PATCH 1/3] initial write-up for linkComponent invoke hook --- 0000-template.md | 52 ------------------------- text/0000-Link-Component-Invoke-Hook.md | 42 ++++++++++++++++++++ 2 files changed, 42 insertions(+), 52 deletions(-) delete mode 100644 0000-template.md create mode 100644 text/0000-Link-Component-Invoke-Hook.md diff --git a/0000-template.md b/0000-template.md deleted file mode 100644 index 10fdec959e..0000000000 --- a/0000-template.md +++ /dev/null @@ -1,52 +0,0 @@ -- Start Date: (fill me in with today's date, YYYY-MM-DD) -- RFC PR: (leave this empty) -- Ember Issue: (leave this empty) - -# Summary - -One paragraph explanation of the feature. - -# Motivation - -Why are we doing this? What use cases does it support? What is the expected -outcome? - -# Detailed design - -This is the bulk of the RFC. Explain the design in enough detail for somebody -familiar with the framework to understand, and for somebody familiar with the -implementation to implement. This should get into specifics and corner-cases, -and include examples of how the feature is used. Any new terminology should be -defined here. - -# How We Teach This - -What names and terminology work best for these concepts and why? How is this -idea best presented? As a continuation of existing Ember patterns, or as a -wholly new one? - -Would the acceptance of this proposal mean the Ember guides must be -re-organized or altered? Does it change how Ember is taught to new users -at any level? - -How should this feature be introduced and taught to existing Ember -users? - -# Drawbacks - -Why should we *not* do this? Please consider the impact on teaching Ember, -on the integration of this feature with other existing and planned features, -on the impact of the API churn on existing apps, etc. - -There are tradeoffs to choosing any path, please attempt to identify them here. - -# Alternatives - -What other designs have been considered? What is the impact of not doing this? - -This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. - -# Unresolved questions - -Optional, but suggested for first drafts. What parts of the design are still -TBD? diff --git a/text/0000-Link-Component-Invoke-Hook.md b/text/0000-Link-Component-Invoke-Hook.md new file mode 100644 index 0000000000..0918e0a830 --- /dev/null +++ b/text/0000-Link-Component-Invoke-Hook.md @@ -0,0 +1,42 @@ +- Start Date: (2017-06-12) +- RFC PR: (leave this empty) +- Ember Issue: (leave this empty) + +# Summary + +Right now there's no public API surrounding the LinkComponent's `_invoke` method. Adding this would allow for addons and applications to extend the LinkComponent and easily add logic gates around the `_invoke` as well as allow for added functionality prior to the transition. + +# Motivation + +- Analytics and click tracking +- Open routes in modals based on environment + +# Detailed design + +Right now the `init` directly hooks the user-defined event type to fire the `_invoke` which is private. `_invoke` then directly works on the transition to the new route. + +A new public method `eventAction` will be bound during `init` instead of the `_invoke`. `eventAction` simply calls `_invoke`. + +Extended components can now override `eventAction`, perform additional logic such as metrics/click-tracking and also logically gate a call to `_super` which would continue execution to transition the route as normal. + +# How We Teach This + +Recommend making this change as unobtrusive as possible and silently adding the new method to the documentation. Several very common addons will likely benefit from this change and can likely move off of some private overrides currently being used. + +Most Ember consumers will benefit from this change via addon updates, rather than direct usage. + +# Drawbacks + +Adding additional features is a difficult sell as LinkComponent is likely set to be reworked into a more modular approach. + +# Alternatives + +Also considered adding a `shouldInvoke` method that returns a boolean and then having `_invoke` call `shouldInvoke` at the head of the function. `_invoke` would then NOOP if `shouldInvoke` returns `false`. + +This approach is less clear as a means to add additional pre-invoke logic. + +While Ember does use `should` prefixes to a certain extent, it is far from a common naming scheme currently. + +# Unresolved questions + +Is it worth making this change, albeit a very small one, in light of current mentalities to break LinkComponent down into a collection of more specific micro-components? From b70b14a8193bad506540776d8f139171c7e0cb20 Mon Sep 17 00:00:00 2001 From: J Corley Date: Mon, 12 Jun 2017 15:55:36 -0500 Subject: [PATCH 2/3] removed placeholders and unnecessary parens --- text/0000-Link-Component-Invoke-Hook.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-Link-Component-Invoke-Hook.md b/text/0000-Link-Component-Invoke-Hook.md index 0918e0a830..61c8b5baa2 100644 --- a/text/0000-Link-Component-Invoke-Hook.md +++ b/text/0000-Link-Component-Invoke-Hook.md @@ -1,6 +1,6 @@ -- Start Date: (2017-06-12) -- RFC PR: (leave this empty) -- Ember Issue: (leave this empty) +- Start Date: 2017-06-12 +- RFC PR: +- Ember Issue: # Summary From 1b664358a5d3ac9ca5b3a6c6473b00fa90d123a9 Mon Sep 17 00:00:00 2001 From: J Corley Date: Tue, 20 Jun 2017 08:04:49 -0500 Subject: [PATCH 3/3] accidentally mv the template instead of cp --- 0000-template.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 0000-template.md diff --git a/0000-template.md b/0000-template.md new file mode 100644 index 0000000000..10fdec959e --- /dev/null +++ b/0000-template.md @@ -0,0 +1,52 @@ +- Start Date: (fill me in with today's date, YYYY-MM-DD) +- RFC PR: (leave this empty) +- Ember Issue: (leave this empty) + +# Summary + +One paragraph explanation of the feature. + +# Motivation + +Why are we doing this? What use cases does it support? What is the expected +outcome? + +# Detailed design + +This is the bulk of the RFC. Explain the design in enough detail for somebody +familiar with the framework to understand, and for somebody familiar with the +implementation to implement. This should get into specifics and corner-cases, +and include examples of how the feature is used. Any new terminology should be +defined here. + +# How We Teach This + +What names and terminology work best for these concepts and why? How is this +idea best presented? As a continuation of existing Ember patterns, or as a +wholly new one? + +Would the acceptance of this proposal mean the Ember guides must be +re-organized or altered? Does it change how Ember is taught to new users +at any level? + +How should this feature be introduced and taught to existing Ember +users? + +# Drawbacks + +Why should we *not* do this? Please consider the impact on teaching Ember, +on the integration of this feature with other existing and planned features, +on the impact of the API churn on existing apps, etc. + +There are tradeoffs to choosing any path, please attempt to identify them here. + +# Alternatives + +What other designs have been considered? What is the impact of not doing this? + +This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. + +# Unresolved questions + +Optional, but suggested for first drafts. What parts of the design are still +TBD?