0

So I'm trying to build an app that has two different kind of users, namely customers and sellers. The app is designed in such a way that both of them will have different kind of navigation bars and access to different kind of pages via routes. As such, I'm trying to see what is the best way to achieve this? I'm thinking of either of the following solutions: 1. using compose binding or areas in my shell.html and by having a container and based on a certain condition, the correct specific view (partial view)will be injected and the default binding context will be a common shell.js. However, the nav bar and each navigation panel displayed is determined by the routes that have 

nav:true

and both seller and customer will have different routes that are marked nav:true. Is there a way to work around this limitation if we use this approach? 2. using compose binding but having two different views and viewmodels that we bind to our shell.html and shell.js. In other words, there will be two routers. However, I've read a number of posts about having two routers and apparently having multiple main routers in an app is not suggested. Is there another way I should approach this?I was having thinking of having multiple SPAs but I figure that would not be efficient since this is a mobile app. Any help or suggestion is greatly appreciated!

Kendrick Lay
  • 15
  • 5

1 Answers1

1

You could simply develop two separate SPAs, but have them share much of the same codebase. With this approach, there's nothing special going on, other than your responsibility to modularize your code for reuse.

This approach would also eliminate the need to incorporate extensive logic throughout to curtail, trim, or augment the web app based on the user currently logged in.

  • Thanks @EricTaylor! I think you are right, it eliminates a lot of logic on views/view models needed to adjust the web app based on the type of user .What is the downside to having multiple SPAs btw? Also would having multiple routers map to your app host using compose binding be a good alternative approach? – Kendrick Lay Jan 29 '15 at 20:00
  • 1
    @KendrickLay So long as your underlying, shared codebase is well-designed, I don't see a down side. It would be difficult for me to speak to the routing issue as we use routing only for the highest level modules. We otherwise are entirely compositional. –  Jan 29 '15 at 20:02
  • Ok thanks! One question though, if I make multiple SPAs and at the beginning, my app is authenticating a user who is trying to log in to see the type of user he is, how do we direct him to the right SPA with respect to App start? The way I plan to structure my app is initally everyone will have a customer account and then you can sign up as a seller account afterwards and the seller account will have additional features on top of the existing features. – Kendrick Lay Jan 29 '15 at 20:27
  • 1
    @KendrickLay That's a good question. What I would do is set up two separate web apps on two separate servers, but that hit the same Active Directory. You could create a unifying landing page that offers two login buttons, one for customers and one for sellers. Behind each successful login would be a redirect to the proper server and app. Does that make sense? As for the additional features of the seller account, that would simply be a matter of extending the common codebase to specialize accordingly. –  Jan 29 '15 at 21:03
  • Thank you @EricTaylor for helping! I think I figured out how to implement two different SPAs based on what you suggest. – Kendrick Lay Jan 30 '15 at 00:03