Over five years ago I released MvcFlash, and soon after I released the second iteration MvcFlash2. Don't let the terrible naming and versioning fool you, this is one of my favorite creations. As ASP.NET 5 starts to take root and MVC 6 blossoms, I begin to feel more confident about creating the next version of MvcFlash. Honestly, I can't see developing an MVC application without it. Before I do, I thought I would muse about the possible challenges ahead.
Why Do We Need Flash Messages?
We want to provide as much feedback to our users as possible when they are interacting with our application. At the same time, we want to keep our actions as atomic as possible. Take for example the following interaction with a contact form.
The action is performed after the form is posted to our server. Only at that time do we know the outcome. Regardless of the outcome, we want to provide the user with feedback at this point and then redirect them to their next action.
MvcFlash offers the following:
- Opinionated methods that provide structured messages: Info, Warning, Error
- Messages are persisted until they are presented to the user (N+ redirects)
- Messages are unique per user/request via
- Views are leveraged to provide first class template support
While you could use the
Session directly, MvcFlash provides a very nice abstraction over those simple APIs.
With MvcFlash 3, I'd like to develop it differently this time, due to the direction of ASP.NET 5 and MVC 6.
- Session is no longer as forgiving as it was in previous versions of .NET. Lack of prior session features means I can't stuff short-lived but complex messages there anymore. I'm also not sure I want to store anything there anymore, and more likely opt for leveraging something like Redis directly.
- With Session being optional, MvcFlash no longer can depend on it and such needs to most likely depend on another mechanism(s) of identifying a user.
- ViewComponents, as described by Dave Paquette, may be a better fit for flash messages than the previous partial view approach.
- Baked in dependency injection simplifies things greatly for me.
- A unified pipeline for web applications, APIs, and SignalR apps could allow me to flash messages in new and exciting ways.
- The MVC
ViewEngine was always the muscle behind MvcFlash and will probably continue to be.
- Cloud First: MvcFlash was initially designed for one server deployments, and while it works in Windows Azure it has been less than perfect. It is time to build a library battle hardened for the cloud.
MvcFlash has been a stable of many of my ASP.NET MVC applications. I want to create more ASP.NET 5 and MVC 6 applications, but don't wish to lose the power that MvcFlash has afforded me over the years. Sadly I can't just carry over the library, but where there is a void, there is an opportunity for new work. I hope to get started soon and continue flashing my users for years to come. :P
I'd love to hear any feedback or advice. Feel free to comment here or reach me on Twitter @AquaBirdConsult.