I know that Mobx-state-tree mentions tcomb as an influence - is it possible to have mobx-state-tree models shared between the front end and backend, so that I can perform validation checks using tcomb-validation or should I just use the models and try to apply snapshot and surface those errors?
Yes, assuming your MST models are in pure JS, you can use them in any JS runtime: browser, node, RN, etc.
Related
This question is about the "correct" design pattern, not about functional code. I want to adhere to best-practices and use the right feature in Laravel.
I have a model called Order which contains users' product orders.
Order has several columns, like which product, quantity, etc, and is stored in mysql, with a belongsTo() call to the User model.
When I place an order using the OrderController, I call an outside API that I set up using a Service class.
Here's the main part of the question:
I need to add certain fields that the API requires, but on my end are always the same, so it would make sense to me to pack these into an object of their own and just append that object to the end of my Order data before submission.
So where is the "Best" place to put this extra data? In my model? In a Service class? I'm leaning toward the service class, but that just doesn't feel right.
You have an action that gives a single or a collection of a model. So the best practice for adding some extra data to those results is using JsonResource and ResourceCollection. By using them you can easily add anything you want in the ToArray method.
Lumen doesn't have Illuminate\Http by default but you can add it to your project.
Official Http package of laravel
Eloquent: API Resources Documentation.
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.
Quick question, what is the difference between Eloquent: API Resources and Fractal?
To me, it looks like the same thing?
Both are used to transform API json responses to standardise the response structure.
However, API resources is inbuilt in Laravel and it's very easy to use. Fractal was the preferred way to go when API resources were not in-build in Laravel. Fractal has some methods which make it little extensive as compared to API resources.
But if you consider the core functionality, both are same with different syntactical sugar.
Most of the things which were in fractal, you can do natively in Laravel now. Plus API resources eliminate the need of any extra installation and setup. The nomenclature is very easy in API resources to start with
both of them are created for one job but their solutions are different in many ways.
Relationships:
in fractal you can easily add related models to the response. also, you can control when the related models should be presented in the response . (default include vs Available include)
for example your client can use ?include=rate to get the rate model from an article when needed! consider that, the fractal will eager load your relationships when you forgot to load it.
in API Resources you have no control over relationships and you should decide to have relationship or not in the first place. otherwise, if you forgot to eager load data for it, it will cost you too many queries to load related model (1+n problem).
Serializer
in basic usage of api resource you have no control on how data will map to final response.
for example if you want jsonnapi specification for your responses, you should manage all of the works by yourself. but in fractal you have it in the first place.
as a conclusion
i recommend you to use fractal in this case. (or use dingo package for api but consider complexity of dingo !!)
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.
I am working on a application in Enyo which has several submodules, each is having its own model and view. Now among those modules, few modules have data that are same and a sync between those is done using binding which means a change in value of some data affects other module data.
I was thinking to make a common model for shared data and separate model for unique data in each module so that binding cannot play further, thus saving some crucial time. So far I have never seen a view to adapting two models altogether. This raises a question that whether is it possible for a view to have two models altogether?
Is there something in Enyo 2.4 MVC architecture that can help me?
I'm not sure I completely understand what you're trying to do, but it sounds like you might want to look at using enyo.ModelController. It will allow you to more easily "swap" a model for a particular component.
Also, you can associate any number of models with a component and bind it up how you like:
enyo.kind({
name: "MyView",
model: theSharedModel,
unique: theUniqueModel
bindings: [...]
});
You can easily do that. Perhaps place your common model onto the App object and your individual view models can live on their respective views. Bind the shared properties using ".app.sharedModel.property", for example.