I'm embarking in my first spa mvc 4 app and I've watched the Steve Sanderson talk which was great but his final delivery tracker app ends up with 3 views that are all declared in the same view page. This is fine for a small app but how do you manage this on a larger scale when you have different sections of the site that have different data. The site I want to build needs to remain on a single page because I want to keep a chat window open similar to the Facebook style chat and i am going to be using SignalR to push data to the client in fixed sections within the app. Do I just use the #Ajax.actions to load up completely different sections of my site much as I would if I was just creating a non spa site? The plan is to keep the user in a specific section of the I site for a majority of the time, but I will want settings pages and user profile management pages that are defined in separate views.
Any good sample code would be greatly appreciated I'm planning to just use the bog standard spa with knockout and nav.js unless someone can suggest a more mature spa technology for mvc/entity framework that's got some good documentation and is popular.
What I do is poor mans SPA, which is basically make my site like a standard ASP.NET MVC app so I have multiple views, multiple controllers and actions and I have a shell page with a container div which I use as the container for the whole site to load my views into with Ajax calls, so I have lots and lots of jQuery ajax calls, I've somewhat tried to refactor my client side JS and make a generic navigate to Javascript method (among other things) in my shell page, which I then invoke from the child views, so a click on a certain ActionLink in a particular child view and I would call my generic JS page loader:
GoToPage(controller, action, query)
which will use jQuery Ajax to lad the destination controller/action/view into the container div in shell.cshtml. For navigation I use Ben Alman's hashchange plugin to detect hash change events and load the appropriate views into my container div. There are obvious downsides to this approach as you're rally not building a real SPA, you're making a server side app with a SPA facade, and actually the performance difference between this and a proper spa which only gets data from the server (not HTML) is slightly noticeable, however if you're a traditional ASP.NET MVC developer this saves you from having to take up new libraries like Sammy.js and knockout etc. The biggest downside of this is that you'll be writing a lot of repetitive wiring javascript which can quickly become a tangled mess, especially if you have a lot of forms. Though you can take certain steps to re-factor and reuse common code. So in summary generating views server side and retrieving them with Ajax probably isn't the most optimal SPA solution, but for me it had the least learning curve (none actually lol). I've recently been looking at Durandal and I think it finally provides a very viable solution to creating SPAs, I specially like how unlike Sammy.js you don't have to load all views on the initial page load, even if the user isn't going to visit those pages. A nice getting started tutorial is provided here.
Related
I have just picked up Vue and am trying to figure out the best way to structure this project.
Requirements:
A basic MPA (traditional site) with about 6 pages. This will be static info.
There will need to be a login section where customer will transmit data via form. Payment will happen here as well so will need to be secure.
My question is how should I be using Vue here? (I've already used VueCLI to scaffold out the project)
Should I:
A) use it for some components (Navbar, buttons, forms, etc) and keep structure traditional? How would i build out the User Dashboard to submit form info in this case - just as a new page?
B) or should I build this whole site as a SPA and have the new 'page' info loaded in on click? This would be easier for the login section?
One thing that may be clear on reading this is I don't understand well how the site will recognize users and deal with logins. Would this be easier if it were structured as a SPA? (more secure?)
(Also, I'm using this site to teach myself front-end development, specifically would like to learn more about building SPAs - so I realize I could use a web editor or easier solutions, but want to learn how to do a lot of this from 'scratch')
From what you've described it is entirely up to you. Both SPA or MPA would work fine and either would be totally reasonable given the requirements.
Have you worked with Vue-router before? SPAs don't need to appear as a single page to the user. They can still function as an MPA with different routes, page files, permissions, etc.
If you are hoping to use this project to teach yourself front-end web dev and know you have a particular interest in learning about SPAs, I think that is your answer.
I would go with an SPA and set up vue-router to manage your routes, and pages.
I am currently working on an asset manager for network/server infrastructure in vue.js.
I am also using vuetify for the look and feel since the goal is to create a progressive web app. Engineers can use their phone to scan tags on company assets to request details.
Currently all data is loaded into the app using a rest api. I am using vuex for state management in the application.
I would like some insights in to when to launch these api requests.
So there is some data i currently load at the start of the web app just after logging in when the main core view is loaded. This is impacting performance. Some examples of loaded data:
-> asset types,vendors,suppliers,...
This data is used in a lot of places in the application. (forms,filters,...)
I prefer not to call the vuex actions to perform the api request form inside a specific component since this could lead to unnecessary request when browsing the app.
The only exception to this being the assets them self since this is a lot of data to load at the start.
The problem i am facing is that on mobile platforms loading the data each time at the start of the app is a waste of data connection. It is possible that the engineer is using the app without actually needing the data.
I know this is kind of an abstract question, i am not looking for the one final awnser. Just some insight or recommendations from the community.
Correct me if I misunderstood but it sounds like you are prefetching a lot of non critical information all at start up. You should really focus on when that data is actually needed and reach out and retrieve it only when its actually needed. A common case of this is on route change, so if you have multiple pages within your app an admin page is likely going to need data that your home screen doesn't need. Wait until you navigate to that page before you retrieve information specific to that page. This is commonly done within the beforeRouteEnter router hook or created life cycle hook. Now to build on this, it may take some time to download that new data after a route change - the page could render before all of its necessary data has been made available. You can use a library like Vue-Promised to handle that intermediate state for sections that require data that is still loading. This allows you to let the page render quickly without having to wait on all of its data.
A couple other tips to further optimize things:
If you data that doesn't change often, sometimes it doesn't hurt to persist that data within the browser, either using the Cache-Control http header when making your http calls or by using something like the browsers LocalStorage or one of the hard persistence methods available within the browser. Theres a number of Vuex plugins that make this really easy, ex. vuex-persist. On startup you can load this data from storage which is faster than making a network call, your app will be able to respond faster and you can even go and make that network request in the background to refresh that data after the page has rendered.
If retrieving large sets of data is an issue then you can page the data to retrieve it in smaller chunks and only retrieve additional "pages" fo data when the user needs it. In tables this is commonly done using pagination buttons or infinite scrolling. Theres a number of libraries that do both of these as well, pagination would likely be built into the vuetify libraries table component.
I have started to work on a greenfield web project which will use ASPNET Core and Aurelia. I cannot find a definitive best-practice approach to structuring this on the client. My current thinking is that each app feature will be be a separate Aurelia application, i.e. when a visitor clicks on the link "Accounts" the browser will make a server request to https://example.com/accounts. This will return a single HTML page which bootstraps an Aurelia app just for accounts. All the accounts interaction will be delivered using Aurelia. Similarly, if the visitor then clicks on "Dashboard", another server roundtrip will bootstrap the "Dashboard" Aurelia app.
Is this a good way of approaching the problem? I have some concerns around application state - in that there will be cross-cutting concerns and data which I don't want to keep round-tripping to the server every time I need it, e.g. audit logs, user information.
I see that Aurelia has the concept of Features - semantically this is exactly what I want as each of these areas of the app will be delivered as a feature. However, I cannot find any good examples of the use of Aurelia features.
Any comments or experiences in similar projects most welcome.
I don't know if it's the 'best' way of doing it but a lot of the applications I build are user / admin type products.
Rather than building an application for each side I take advantage of child routers and structure my application with a page based convention as described here:
https://ilikekillnerds.com/2015/10/how-to-structure-an-aurelia-application/
I have made an angular app with rails as a backend.I have read lots of blog and articles about how to make an angulajs app crawlable.
for example - : "http://www.example.com/#!/home" Google bots will convert this url into "http://www.example.com/?_escape_fragment_=/home".
I have written logic that wherever request comes with "?_escape_fragement_=" format ,I just returns the json data in html file.
for example-:
<p>name: test</p>
<p>designation :test1</p>
so i just want to know that this much is enough for making an ajax application crawlable.if not then please suggest me the other ways to make an application crawlable.
Thanks,
You should consider creating HTML snapshots from your existing codebase rather than adding further complexity for creating pages. Google (see option 3) recommends using a headless browser to prerender your AJAX application before returning to the client.
You can also see some significant performance improvements by prerendering for all users and initialising your Angular app in its current state - especially in hybrid apps/mobile websites - this reduces XHR requests and painting in the browser. More on this here;
https://github.com/ithkuil/angular-on-server/wiki/Running-AngularJS-on-the-server-with-Node.js-and-jsdom
I'm going to be developing a new system and am toying with the idea of either creating a single page application or a full asp.net mvc website.
I want to utilise knockout so if I went down the mvc route i'd need to load my mvc view and on document ready then make the ajax call to bind to my knockout view model.
Is this a bad approach as i'm effectively making 2 calls to get one page?
Depends really on your exact page design and behavior.
But generally MVC and knockout do not require you to get the data via ajax, you can populate your data from the server then manually apply bindings to your observables.
saving the data could be done via ajax.
Of course its all theory now, you need to see your screen designs and check which way to go.