Skip to content

Fix #71 Hard dependency to MVC setup #72

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Mar 23, 2017
Merged

Fix #71 Hard dependency to MVC setup #72

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
52efd55
Fix #71 Hard dependency to MVC setup
Mar 23, 2017
60a1300
chore(csproj): bump package version
jaredcnance Mar 23, 2017
38d7ba9
style(app-builder-ext): single line if-statements
jaredcnance Mar 23, 2017
2a6bccb
Merge branch 'develop' into develop
jaredcnance Mar 23, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions src/JsonApiDotNetCore/Extensions/IApplicationBuilderExtensions.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,14 @@ namespace JsonApiDotNetCore.Routing
{
public static class IApplicationBuilderExtensions
{
public static IApplicationBuilder UseJsonApi(this IApplicationBuilder app)
public static IApplicationBuilder UseJsonApi(this IApplicationBuilder app, bool useMvc = true)
{
app.UseMiddleware<RequestMiddleware>();

app.UseMvc();
if (useMvc)
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at this point I would question whether or not it should be the responsibility of this library to even call .UseMvc()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so too. However, that would be a breaking change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. I'm fine with the proposed solution. I'd just like to see if there is maybe a better one.

Since the library won't even work without the MVC middleware, what do you think of just adding an overload with a Action<IRouteBuilder> configureRoutes parameter which we can pass into the UseMvc method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I thought about that too. Currently, that is the only available overload for UseMvc, so that would be fine. As soon as there is another overload, you'd need to make this available as well...

Furthermore, I think it matters in which order the Use-Calls occur, so to be completely flexible, another Action<IApplicationBuilder> would be necessary that is called between the app.UseMiddleware<RequestMiddleware>() and app.UseMvc() statements.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JanMattner all good points. I can't think of any circumstances where someone would need to apply middleware in between the two, but that doesn't mean there isn't a use case. That would result in a method signature like:

IApplicationBuilder UseJsonApi(this IApplicationBuilder app, 
  Action<IRouteBuilder> configureRoutes, 
  Action<IApplicationBuilder> intermediateAppBuilderCalls);

which I can't say I'm a huge fan of. I don't think we should further couple it to the MvcApplicationBuilder api. Ideally I'd like to see this deprecated in the future. But, I think this PR is a good start.

app.UseMvc();
}

return app;
}
Expand Down