Skip to content
This repository has been archived by the owner. It is now read-only.

Add ViewBag to PageModel #6754

Closed
JohnyL opened this issue Sep 2, 2017 · 15 comments

Comments

@JohnyL
Copy link

commented Sep 2, 2017

In Razor Pages, I noticed that I can't use ViewBag within my class, but I can use it in a view! I do prefer ViewBag over ViewData. Is there something I'm doing wrong? How to get ViewBag back?

@pranavkm pranavkm changed the title Razor Pages: ViewBag has gone? Add ViewBag to PageModel Sep 2, 2017

@pranavkm

This comment has been minimized.

Copy link
Member

commented Sep 2, 2017

Seems like we missed adding the property to PageModel. For the time being, you should be able to create a custom BasePageModel type with a ViewBag property. Here's the relevant code from Controller: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.ViewFeatures/Controller.cs#L85-L96

@JohnyL

This comment has been minimized.

Copy link
Author

commented Sep 2, 2017

@pranavkm Thanks, this workaround works just perfectly. Would appreciate if it would be out-of-the-box!

@DamianEdwards

This comment has been minimized.

Copy link
Member

commented Sep 2, 2017

We purposefully didn't add ViewBag because I wanted to discourage its use. As @pranavkm points out you can add it back easily enough if you wish but I don't have plans to add it back to the built-in base class.

@JohnyL

This comment has been minimized.

Copy link
Author

commented Sep 2, 2017

@DamianEdwards Could you please explain why you insist on discouraging its use?

@DamianEdwards

This comment has been minimized.

Copy link
Member

commented Sep 2, 2017

Sure, sorry. ViewBag uses dynamic which in our testing introduces a measurable performance impact on the processing of pages or views that use it. As such, I'd rather it not be available by default. We could investigate a simpler mechanism to allow folks to re-enable it if they really wish, but the given workaround seems suitable.

@JohnyL

This comment has been minimized.

Copy link
Author

commented Sep 2, 2017

Well, this is some one-side logic. Perhaps you're telling about high-traffic web sites whose workload is on peek, but as to simple sites this is perfectly acceptable. Moreover, don't forget that typing and reading ViewBag properties is leaner rather ViewData ones. And if one doesn't need it, then he won't use it.

@DamianEdwards

This comment has been minimized.

Copy link
Member

commented Sep 2, 2017

I try to avoid ViewData as much as possible too, limiting to use only for passing values between pages/views and layouts for example. In the future we hope to create features to remove the need for that too. Given Razor Pages is an opportunity to "reset" the first-level concepts and features, we decided to leave out ViewBag as discussed.

@JohnyL

This comment has been minimized.

Copy link
Author

commented Sep 2, 2017

Well, it's a pity it won't be included anymore. I hope with C# 8 "extension everything" I won't have to subclass PageModel and will attach ViewBag directly to it.

@JohnyL

This comment has been minimized.

Copy link
Author

commented Sep 2, 2017

@DamianEdwards
But I still don't understand.

  1. View has ViewBag
  2. PageModel doesn't have ViewBag.
  3. @pranavkm says "Seems like we missed adding the property to PageModel".
  4. You say "we decided to leave out ViewBag as discussed".
    So:
  5. You missed it or it was intention?
  6. What's the point of having it in View but not having in PageModel?
    I really don't understand why excluding it? Let me re-iterate myself: if one doesn't need it, he won't use it.
    If Razor Pages is a "reset" (as you say), then why there's still no other mechanism?
@DamianEdwards

This comment has been minimized.

Copy link
Member

commented Sep 2, 2017

I made the call to exclude it, @pranavkm mis-remembered or wasn't aware of that. I've already answered everything else. Sometimes folks will disagree. You can use ViewData to pass data from the PageModel or the Page to the configured layout page, but beyond that one should be using model properties. You can add ViewBag back by sub-classing PageModel and/or the page base class.

@JohnyL

This comment has been minimized.

Copy link
Author

commented Sep 2, 2017

OK. Thanks for explanations.

@davidfowl

This comment has been minimized.

Copy link
Member

commented Sep 3, 2017

Why do you need it? To pass state to the layout page?

@JohnyL

This comment has been minimized.

Copy link
Author

commented Sep 3, 2017

@davidfowl Yes. @DamianEdwards mentioned that "in the future we hope to create features to remove the need for that too". So, I asked him why there's still no alternative mechanism, but got no answer. And if you get rid of ViewBag, then remove it from View so not to confuse people.

@Eilon Eilon added this to the Discussions milestone Sep 5, 2017

@Eilon Eilon added the discussion label Sep 5, 2017

@poke

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2017

Considering that the page model is already the model for the view, it’s super simple to add additional properties that you can then access in the view. Just add properties to the page model, and you can already access them in the view. And they are strongly typed which is much better than view data anyway.

The same is not true for MVC where you explicitly have to pass a model to the view. So view data there has a little more use.

The primary reason why it’s there in MVC is likely compatibility with classic ASP.NET though. Razor pages not being a part of earlier ASP.NET versions makes for a good opportunity to deprecate view data (by not exposing the ViewBag). There are many differences between Razor pages and controllers, so I don’t see how one having X should mean that the other has X too, as long as you can still solve the same problems.

@pranavkm

This comment has been minimized.

Copy link
Member

commented May 9, 2018

For 2.1.0, we also have support properties annotated with ViewDataAttribute in both controllers and Razor Page models. We recommend using it over using ViewData or ViewBag.

Closing since it doesn't look like there's any further discussion to be had here.

@pranavkm pranavkm closed this May 9, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
6 participants
You can’t perform that action at this time.