Introduced new route declaration syntax #2441

thecodejunkie · 2016-05-11T12:46:51Z

Prerequisites

I have written a descriptive pull-request title
I have verified that there are no overlapping pull-requests open
I have verified made sure that I am following the Nancy code style guidelines
I have provided test coverage for your change (where applicable)

Description

In 2.0-alpha we changed the route syntax and made all the routes async which meant they all had to return Task<T>. We also temporarily introduced LegacyNancyModule which was a custom module class which mimicked the old, synchronous, route behavior with the intent to help people migrate to 2.0 and then we would remove it in a later release (perhaps even before 2.0 RTM). As it turns out, forcing Task<T> on all routes wrecked our syntax a bit it made it difficult to have routes that returned primitives such as int (status code), HttpStatusCode, string (response body) or even to call View or Negotiate. We did try some tricks, like custom awaiters and so on which made the syntax a bit nicer but it still forced you to declare all routes as async and then await

Get["/"] = async (args, ct) => await 200;

Get["/"] = async (args, ct) => await View["index"];

Not too shabby, but it still forces you to declare these simple routes, which aren't async by nature, as async which would cause the entire async state machine to be generated even though you did not need them. Clearly not ideal, and most certainly not very Super-Duper-Happy-Path

Proposal

For quite some time now, we have talked internally about a new route declaration syntax. Not a massive change, but one that would mean we would trade in the indexer syntax Get["/"] (they have been a signature mark for Nancy since day one) for a method based approach Get("/").

See #2441 (comment) for samples

Code change mentions

~~I have introduced a delegate T RouteAction<T>(dynamic parameters, CancellationToken token) which represents the body of a route~~
I have made Route abstract and introduced Route<T>. The base class Route does not contain an Action anymore, the idea is that a Route doesn't per-say need to have an action it just needs to be invocable so you could inherit different kinds of Route if you have any other desires. The NancyModule declarations uses Route<T> which has the Action property of type RouteAction<T> that in turn will be called when Route.Invoke is invoked.
Introduced RouteResultHelper which is used to take a route response, which may or may not be a Task, and coereces the result in a format what we can use it. It does some funky casting with the help of reflection and generic method signatures. This class is used by DefaultRouteInvoker and DiagnosticsHook + in a test where we needed to mock the IRouteInvoker and have it return a proper response.
All route declaration method (Get(), Post() and so on) on NancyModule have been made virtual so you can override and intercept the declarations if you'd like to do something to it before it is stored
dynamic is only used in the route lambdas now, from there on it should be DynamicDictionairy

Worth noting

~~Since we are inferring T you cannot return instances of a private model~~
~~For the same reason you need to explicitly define a model object for routes that returns an anonymous model Get<object>("/", (args, ct) => new { Name = "Nancy" });~~
I have removed LegacyNancyModule as it serves very little point now and converting to the new syntax is very fast

jchannon · 2016-05-11T13:04:28Z

Should we add an overload to remove the CancellationToken from sync routes?

Get("/", (args, ct) => {
   return "Hi"
});

So it becomes

Get("/", (args) => {
   return "Hi"
});

thecodejunkie · 2016-05-11T13:12:48Z

@jchannon yeah, doing that now

thecodejunkie · 2016-05-11T13:49:39Z

@jchannon pushed + updated description

khellang · 2016-05-11T13:52:56Z

src/Nancy/Routing/Route.cs

@@ -56,7 +56,7 @@ public class Route<T> : Route
        /// </summary>
        /// <param name="description"></param>
        /// <param name="action">The action that should take place when the route is invoked.</param>
-        public Route(RouteDescription description, RouteAction<T> action)
+        public Route(RouteDescription description, Func<dynamic, CancellationToken, T> action)


Shouldn't these return a Task<T>?

jchannon · 2016-05-11T14:00:32Z

I see you made the CancellationToken optional but would there be a case where you'd want it on a non-async route?

khellang · 2016-05-11T14:06:16Z

I see you made the CancellationToken optional but would there be a case where you'd want it on a non-async route?

Why/how would you cancel a synchronous operation using a CancellationToken?

jchannon · 2016-05-11T14:07:13Z

@khellang who's that message for?

khellang · 2016-05-11T14:10:23Z

@khellang who's that message for?

You 😄

jchannon · 2016-05-11T14:27:00Z

You wouldn't that's why I'm asking why make it available on a sync route

khellang · 2016-05-11T14:41:13Z

You wouldn't that's why I'm asking why make it available on a sync route

Oh, I thought you were asking if we could add it. The main problem right now is that all the methods accept non-async delegates (no Task<T>) return.

horsdal · 2016-05-11T20:17:03Z

src/Nancy/NancyModule.cs

+        /// <param name="path">The path that the route will respond to</param>
+        /// <param name="action">Action that will be invoked when the route it hit</param>
+        /// <param name="condition">A condition to determine if the route can be hit</param>
+        protected void AddRoute<T>(string name, string method, string path, Func<NancyContext, bool> condition, Func<dynamic, CancellationToken, T> action)


Seems odd to swap the condition and action args around compared to the verb methods.

Ha ha, well spotted! 😄

They weren't really swapped around, but moved out of necessity. The AddRoute parameter order is left unchanged while the verb methods have been rearranged because condition and name are optional.

Makes sense. Guess I'd have swapped them in AddRoute too then.

thecodejunkie · 2016-05-12T08:47:39Z

@khellang me and @grumpydev spent some time this morning verifying the behavior of it not being Task<T> under the premiss that it would be inferred + verified the behavior of the result coercion (found a bug). It all seem to work as expected in terms of asynchronicity https://gist.github.com/grumpydev/048e8ab6fb390dfa53d77d3cc68a4b19

thecodejunkie · 2016-05-16T09:12:50Z

ℹ️ Update the route declaration overloads to support both sync and async routes, both with or without a cancellation token (ignore the silly sample routes, just needed compiling routes to show what it is now capable of)

public class RoutingModule : NancyModule
{
    public RoutingModule()
    {
        Get("/", args =>
        {
            return 200;
        });

        Get("/", (args, ct) =>
        {
            return Task.FromResult(200);
        });

        Get("/", async args =>
        {
            return await Task.FromResult(200);
        });

        Get("/", async (args, ct) =>
        {
            return await Task.FromResult(200);
        });
    }
}

jchannon · 2016-05-16T14:01:44Z

src/Nancy/Routing/Route.cs

+        /// <returns>A (hot) task of <see cref="Response"/> instance.</returns>
+        public override Task<object> Invoke(DynamicDictionary parameters, CancellationToken cancellationToken)
+        {
+            return this.Action.Invoke(parameters, cancellationToken).ContinueWith<object>(t => t.Result, TaskContinuationOptions.OnlyOnRanToCompletion);


Why do you need the ContinueWith

Because this.Action returns Task<T> and we need convert it to a Task<object>

I noticed further up you called an action like action(...) but here you're using Action.Invoke(...) I don't believe it makes much different but, consistency? :)

jchannon · 2016-05-16T21:27:06Z

aidapsibr · 2016-05-17T20:29:58Z

Looking forward to testing this one, I would imagine this will make it simpler to add Swaggeresque metadata overloads in the future or even as an extension.

jchannon · 2016-05-17T20:35:44Z

Yup

On Tuesday, 17 May 2016, Ovan Crone notifications@github.com wrote:

Looking forward to testing this one, I would imagine this will make it
simpler to add Swaggeresque metadata overloads in the future or even as an
extension.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2441 (comment)

phillip-haydon · 2016-05-18T16:17:04Z

samples/Nancy.Demo.Authentication.Forms/MainModule.cs


-            Post["/login"] = x => {
+            Post("/login", args => {


OMG @thecodejunkie can you stop with the inconsistent braces!!! :)

I've not changed a single brace

davidfowl · 2016-05-19T07:24:03Z

I approve of this syntax 👍

grumpydev · 2016-05-19T07:25:40Z

Fowler is agreeing with us.. Anyone else suspicious? 😂

phillip-haydon · 2016-05-19T07:27:39Z

So we can close this PR now?

thecodejunkie · 2016-05-19T07:30:16Z

@phillip-haydon if we have properly reviewed the changes around async stuff then yes.. if no, then we need to review it :P For example are we using ConfigureAwait(false); in relevant places in the change etc?

horsdal · 2016-05-19T07:58:32Z

Reviewed a second time. Didn't find anything 😸

phillip-haydon · 2016-05-19T08:05:48Z

Held up by @khellang as always. 👀

jchannon · 2016-05-19T12:09:08Z

Momentous Day!!

aidapsibr · 2016-05-19T17:19:24Z

May I request a new release for this?

thecodejunkie · 2016-05-24T19:51:53Z

@psibernetic we're working on it. in the meantime you can always grab it of our myget feed which gets built on each new commit to master

aidapsibr · 2016-05-25T00:15:19Z

Yeap thank you, fellas in chat pointed me there, been testing away.

canton7 · 2016-09-21T11:11:16Z

The wiki still needs updating, BTW

thecodejunkie · 2016-09-21T12:23:25Z

@canton7 the wiki will not be updates as the 2.0 packages comes out of pre-release, until then all changes are considered as being pending =)

canton7 · 2016-09-21T13:07:42Z

My bad, apologies for the noise.

steve2 · 2019-03-04T19:12:14Z

Are there ever going to be doc updates that use the new syntax?

thecodejunkie added Breaking Change Improvement labels May 11, 2016

thecodejunkie added this to the 2.1 milestone May 11, 2016

thecodejunkie changed the title ~~Introduced new route declaration syntax~~ [WIP] Introduced new route declaration syntax May 11, 2016

thecodejunkie mentioned this pull request May 11, 2016

Improving route return value handling for primitive values #2437

Closed

thecodejunkie mentioned this pull request May 11, 2016

Made the Negotiator awaitable #2422

Closed

4 tasks

khellang reviewed May 11, 2016
View reviewed changes

horsdal reviewed May 11, 2016
View reviewed changes

thecodejunkie force-pushed the update-route-syntax branch from 5d1740c to bf3bbe9 Compare May 16, 2016 09:09

thecodejunkie force-pushed the update-route-syntax branch 4 times, most recently from ff9e550 to b490c6b Compare May 16, 2016 11:21

thecodejunkie changed the title ~~[WIP] Introduced new route declaration syntax~~ Introduced new route declaration syntax May 16, 2016

jchannon reviewed May 16, 2016
View reviewed changes

phillip-haydon reviewed May 18, 2016
View reviewed changes

jchannon merged commit 4d9c30e into NancyFx:master May 19, 2016

xt0rted mentioned this pull request May 27, 2016

Update route syntax in readme #2468

Merged

4 tasks

thecodejunkie mentioned this pull request Sep 27, 2016

Async all the things #2576

Open

3 tasks

Introduced new route declaration syntax #2441

Introduced new route declaration syntax #2441

Conversation

thecodejunkie commented May 11, 2016 • edited

Prerequisites

Description

Proposal

Code change mentions

Worth noting

jchannon commented May 11, 2016

thecodejunkie commented May 11, 2016

thecodejunkie commented May 11, 2016

khellang May 11, 2016 • edited

Choose a reason for hiding this comment

jchannon commented May 11, 2016

khellang commented May 11, 2016 • edited

jchannon commented May 11, 2016 • edited

khellang commented May 11, 2016 • edited

jchannon commented May 11, 2016

khellang commented May 11, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thecodejunkie commented May 12, 2016

thecodejunkie commented May 16, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jchannon commented May 16, 2016 • edited by thecodejunkie

aidapsibr commented May 17, 2016

jchannon commented May 17, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidfowl commented May 19, 2016

grumpydev commented May 19, 2016

phillip-haydon commented May 19, 2016

thecodejunkie commented May 19, 2016

horsdal commented May 19, 2016

phillip-haydon commented May 19, 2016

jchannon commented May 19, 2016 • edited

aidapsibr commented May 19, 2016

thecodejunkie commented May 24, 2016

aidapsibr commented May 25, 2016

canton7 commented Sep 21, 2016

thecodejunkie commented Sep 21, 2016

canton7 commented Sep 21, 2016

steve2 commented Mar 4, 2019

thecodejunkie commented May 11, 2016 •

edited

khellang May 11, 2016 •

edited

khellang commented May 11, 2016 •

edited

jchannon commented May 11, 2016 •

edited

khellang commented May 11, 2016 •

edited

jchannon commented May 16, 2016 •

edited by thecodejunkie

jchannon commented May 19, 2016 •

edited