So to help me understand something. For further info I'm using Laravel as a backend language and Vuejs as frontend.
A user wants to visit a page to view a specific project that hits the show method on my controller. The show method loads all data pertaining to that project to display on the page. This show page is made up of many different view partials and inside some of those partials are different Vue Components that will display different sets of data pertaining to the project. Is it better to just pass all the data through props to the different Vue components that are needed or just pass in the whole project as a prop and then reference the properties of the project inside the component? Or should I pass the project Id and then have methods to fetch the specific data for that component with use of the project id.
I think that the three approaches you mention are perfectly valid. It depends on how you want to structure your components.
Do you want to use "dumb" or generic components that don't know about the structure of a "project"? Then your main component should pass relevant pieces of data to the children components.
Are children components specific to "projects" and not reusable anywhere else? Then passing the project reference around and each component getting the pieces of data they are interested in is also a good strategy.
I would probably avoid last option to avoid multiple server round trips, although it can be useful in case there is a specific part of a project that takes a lot of time to retrieve (for instance a list of sub-tasks). You could split the data fetches in two or three calls to make the main view render fast while the time-consuming query is still executing and populated when available.
Related
I am trying to decide on the best solution to loading form options dynamically with a restful api approach in mind. Im using laravel for the back end and Vue components to handle the frontend that live inside blade templates where necessary.
Currently my controllers all return a blade view that contains Vue components which handles all the front end stuff such as forms etc. So I am just wondering what the best approach would be to loading options for a select. I've thought of a few ways:
Pass the options necessary to the view and define them as props on the component.
Keep it as is and when the vue component loads go and fetch options via an api endpoint.
The problem with approach 1 is that my components are tightly coupled to the view it belongs to and I have to make sure in every controller that returns a view where a component requires some options i would have to pass down a potentially random set of collections to the view for example a collection of companies and roles could be passed down to the user edit view and assigned as props which can bloat the controller and cause confusion where it's not immediately clear what those collections are intended for unless you go to the component that's using them.
With approach 2 I can have a generic select component that takes a url as a prop and can easily reuse it everywhere with v-model. The problem with this approach is it doesn't feel right to have an entire route dedicated to return a different structure of an existing route for example:
/api/company/1/users -> returns array of entire objects and relationships
/api/company/1/users/options -> returns array of only id and name
The best solution I could think of is to go with option 2 and use the original route but with a parameter to determine the response structure:
/api/company/1/users?options=true -> controller checks for options and returns option version of users instead of all attributes+relationships.
So is there an ideal approach to handling this? Both approaches work but I'm hoping to get some advice on the best approach or there might be another way I haven't thought of.
Thanks.
i'm doing a app and i have an ajax call that send the data to the server and ask the db,it retrieves me the object data.Until here everything is cool.But i want to do a route with routie to retrieve the results on it'own page. the problem is that the two component are at the same level on the hierarchy, so cant get the props of the state data 😥. I've heard about flux but it's a pretty complex architecture for the project that i'm doing. Do you guys have a good pattern to solve that ?
Very Gratefull ;)
I dont think you need Flux for this. You can not (or at least should not) pass data between Components which are on the same hierarchy level. You should read the following lines: https://facebook.github.io/react/docs/thinking-in-react.html#step-4-identify-where-your-state-should-live
It gives you same hints on how to decide where to put your state by defining some simple rules.
Simply put the necessary logic into a common owner of your two components (so one or more level up in the hierarchy).
What we usually see in framework documentations are simple blog-like applications where each page is related to only one model and one controller.
How to deal with the most common case where a single page have to display information from different models?
Example:
A social network home page that shows:
Recent user posts
Recent users
News from the admins
Most played games
Is this supposed to be handled by a single controller that loads all this information from the different models and send it to a view that is potentially broken down into partials / elements?
Someone said in another question that I could create something like a HomePageController for pages like this. What if all that information should be displayed in the sidebar for all pages on the site, how do I handle that?
Typically, you'll collect all the different kinds of data and pass it to the view together:
MVC frameworks generally provide some way to map request URLs (e.g. /offers?id=5) to controllers (or their methods).
Let's assume that you want to display some data on your homepage.
To do this, you'll first define mapping from URL /home to some particular controller, let's say HomePageController.
Using your example data, you'll have something like this in your controller (in method that will handle request):
model.add(dao.getRecentUserPosts());
model.add(dao.getRecentUsers());
model.add(dao.getNewsFromAdmins());
model.add(dao.getMostPlayedGames());
render("viewName", model);
Upon request to some adress mapped to this specific controller, you will get different kinds of data from your Data Access Object (dao), and the add them to your model.
Once model is filled with data, you can pass it to a view ( = render view with this model), and in view you'll display it any way you want to.
I hope that basic flow is now clear to you.
Referring to #BeK's answer:
handling requests that take longer will always need an individual approach. You may choose to load this part asynchronously, you may (and probably will) try to cache as much as you can.
Loading the sidebar:
most of MVC frameworks provide some kind of 'base template' for your view.
That means you can define one part of view (e.g siderbar or footer) that is displayed on every page, and in particular controllers you only care about the dynamic parts. Those solutions are flexible enough to satisfy most of the typical needs.
There are a lot of options depending on what are you displaying in that sidebar - is it static or dynamic? what can be cached? etc.
There are several options here. It really depends on what kind of data you are loading. If one of the data requests takes a long time the view will not be displayed until all the data is gathered. If you break the view down in partials and let them load async, the user will have a better UX. In this way you can have the separate controllers/controller methods, complying with patterns like SRP.
If you want all the data to be displayed in the sidebar of every page, than maybe one controller taking care of it will be an easier solution, but again I would suggest take a look at the data you are loading and especially the time it takes to load all the data. Hope this answers your question or sets you on the right path.
alternate approach to follow SRP is using MVC child actions.
create many models and controller. each controller responsible for its own business logic
eg.
PostsController
NewsController
GamesController
HomeController
starting from HomeController that render the HomePage.cshtml
<div>#Html.Partial("Login.cshtml", Model.CurrentUser)</div>
<div>
<hgroup>
<h2>what's new</h2>
</hgroup>
<div>#Html.Action("WhatNew", "News")</div>
<div>#Html.Action("RecentlyPosted", "Posts")</div>
</div>
<aside>
<h2>Games</h2>
<div>#Html.Action("MostPlayed", "Games")</div>
</aside>
you may fetch list of many controller/actions name as string in HomeController then render multiple child actions in main page.
I have this idea of generating an array of user-links that will depend on user-roles.
The user can be a student or an admin.
What I have in mind is use a foreach loop to generate a list of links that is only available for certain users.
My problem is, I created a helper class called Navigation, but I am so certain that I MUST NOT hard-code the links in there, instead I want that helper class to just read an object sent from somewhere, and then will return the desired navigation array to a page.
Follow up questions, where do you think should i keep the links that will only be available for students, for admins. Should i just keep them in a text-file?
or if it is possible to create a controller that passes an array of links, for example
a method in nav_controller class -> studentLinks(){} that will send an array of links to the helper class, the the helper class will then send it to the view..
Sorry if I'm quite crazy at explaining. Do you have any related resources?
From your description it seems that you are building some education-related system. It would make sense to create implementation in such way, that you can later expand the project. Seems reasonable to expect addition of "lectors" as a role later.
Then again .. I am not sure how extensive your knowledge about MVC design pattern is.
That said, in this situation I would consider two ways to solve this:
View requests current user's status from model layer and, based on the response, requests additional data. Then view uses either admin or user templates and creates the response.
You can either hardcode the specific navigation items in the templates, from which you build the response, or the lit of available navigation items can be a part of the additional information that you requested from model layer.
The downside for this method is, that every time you need, when you need to add another group, you will have to rewrite some (if not all) view classes.
Wrap the structures from model layer in a containment object (the basis of implementation available in this post), which would let you restrict, what data is returned.
When using this approach, the views aways request all the available information from model layer, but some of it will return null, in which case the template would not be applied. To implement this, the list of available navigation items would have to be provided by model layer.
P.S. As you might have noticed from this description, view is not a template and model is not a class.
It really depends on what you're already using and the scale of your project. If you're using a db - stick it there. If you're using xml/json/yaml/whatever - store it in a file with corresponding format. If you have neither - hardcode it. What I mean - avoid using multiple technologies to store data. Also, if the links won't be updated frequently and the users won't be able to customize them I'd hardcode them. There's no point in creating something very complex for the sake of dynamics if the app will be mostly static.
Note that this question doesn't quite fit in stackoverflow. programmers.stackexchange.com would probably be a better fit
I am creating a front-end for a data collection web application. Operators using the data collection application will log data for a dozen different projects, with each project requiring different fields. There are some common fields (like name, address... etc) but then each project also has custom fields for extra data that needs to be collected. Some projects require dozens of extra fields, while some projects require only 1 or 2 fields. Can anyone think of a "clean" way to handle this situation? I don't want to create an input page for each project, and some people are tossing around the idea of doing UI templates in XML. Any guidance would be much appreciated.
XML would provide a neat solution to your problem. Depending on the user choice, ask the user to fill more fields. From your problem statement its looking that you know how many projects need extra fields and which do not. If you know this data then feed this data into a database and then accordingly generate your form page. However even if the data is available dynamically with the use of an interactive javascript and ajax you can easily achieve a neat solution.