In Laravel I am used to define my models up front and to perform all actions on them.
However, it seems that most frontend frameworks just use whatever an API reponse provides and store the json data into simple arrays.
The only framework that I found using the model approach is Ember. I am missing this structure in the vue docs. I wonder why nobody seems to care about models. Are they just not that important in the frontend world?
Using models in frontend frameworks is not that common due to JavaScript as a language. There are many benefits to strong typing, which is why there are nowadays multiple ways to add typing to the language.
Vue has support for TypeScript which is a common way to define models in your JavaScript. TypeScript let's you define interfaces with certain types, so that you know that the data you have conforms to your model.
That's where TypeScript comes in handy, Vue supports it, I don't know much about ember but I've found this and Angular has it out of the box. As far as I know backend developers learning front end technologies like Angular and TypeScript over other options because of the coding style.
Related
I am interested in taking up a learning path which would include web application development using Dashboard Admin UI Kits such as these Link to example
What application and or languages are used when implementing such a
UI ?
What databases are to be used in the backend?
For the UI:
Languages are always the same: HTML, CSS, JavaScript. Yet, they have countless libraries.
For CSS, I would check Bootstrap (or Bulma if you want slightly less pain), which is a simpler but richer one compared to many others.
For JS, I would check some animation libraries (there are many), and probably not start with any JS framework such as React, Angular etc. They might come later once you feel comfortable with JavaScript.
For HTML, you already have dashboard kit already. Though a great idea for learning, but as far as I know using templates is not a common practice for bigger companies etc.
For the backend:
It really depends on what you want to focus more on. Programming languages have advantages and disadvantages. You can work with (almost) any language but increasingly more popular ones are Node.js, Django (Python's popular web framework) etc. For beginning, these two are nice options. Node.js is also closely related to JavaScript, so that is a big plus.
For the database:
You might want to check if you need relational data or not, because that might narrow down your options. MongoDB is easy to learn and to get the basics of backend programming, while SQL (PostgreSQL is a nice example) is a widely preferred SQL option one in the industry.
I am refactoring my first pass Vue dashboard application, which uses vue-chartjs to access chart.js.
As part of doing this, I am creating a set of wrapper components that encapsulate more functionality than just the chart itself, e.g. titles, dialogs, measures etc. In doing this, I am finding that how vue-chartjs adds complexity to my task for multiple reasons, e.g. the structure of renderChart props doesn't match the parameters of chartjs itself. Also, vue-chartjs has its own unique capabilities that add a layer of complexity to using chartjs.
I assume there are other complexities that are reduced by using vue-chartjs, but... my question is:
Do experienced Vue developers use vue-chartjs to access chart.js? Or do you go direct to chart.js? My first pass approach was derived from a tutorial, and I didn't question it at the time. Now that I'm doing more complex things, vue-chartjs is getting in my way as I try to simplify and minimize data marshaling.
For now I am working around these issues, but if it is reasonable to create my own wrappers rather than add an unnecessary level through vue-charts, I would like to try that. But I don't want to venture into this without first asking for feedback from other dashboard folks who have done it!
Thanks for any advice on this.
Anecdotally speaking, I've found in some code reviews less experienced devs tend to rely on vue-**** wrapper libraries even when there is little (or even no) benefit. Adding additional libraries increases exposure to more dependencies, each of which theoretically carries a potential for security vulnerability. I've also seen the opposite, where the functionality is re-invented when a vue library is available and would save significant amount of time and have a more robust component(like including aria fields or thoroughly tested with various browsers). The tl;dr; being, I take is on a case by case basis.
I agree with #Daniel. I can give another example where I used vue-popper wrapper package. The component itself is not bad, it's well done, however, it uses the previous major version of popper.js which lacks good new features and improvements. For this reason I created later my own implementation of vue popper with the latest version.
I have been reading about the new Composition API that is about to be introduced in Vue 3 which is set to release this year.
While I have been studying and exploring about the topic, I fail to understand why the word "API" is used. As far as I know, an API is used for sending/fetching data between the browser/app and a server.
Also, the Composition API is set to be an optional replacement for the already existing Options API in Vue 2. Even here, I do not understand the use of the word "API" in Options API.
Can someone please explain?
An API is not restricted to interfacing with servers. In general, they are well defined layers that give you intuitive access to things that are more complex. You're constantly interfacing with things every day; imagine the steering wheel of a car being the interface to the front wheels.
The API is how you interact with Vue. It's an agreement for how your code interacts with the underlying logic in Vue. The team have introduced the Composition API because they believe it will help in creating cleaner, faster and more maintainable code.
The Options API is so called because you pass options in an Object when instantiating a Vue component. The Composition API is so called because you use composition functions to add functionality to a Vue component.
I'm trying to get an initial understanding of what a full Elm application looks like. In particular what the "stack" looks like. As a concrete example, let's say I have a website that allows users to register/login and then upload pictures and comment on others' pictures and comments. It delivers HTML, JavaScript, and CSS, and uses PHP and/or Perl on the server, The PHP/Perl interacts with MySQL or Oracle. If I were to re-develop this site with Elm, what parts does Elm handle and what are the common/recommended choices for the rest of the stack?
Elm handles the frontend responsibilities. You can use it instead of javascript and use its libraries to generate the needed html & css.
For backend you can use whatever technology you want. Since Elm is a functional language, some people chose a functional language for the backend too. Most frequent I've seen are Elixir (Phoenix Framework) and Haskell.
Take a look at Tour of an Open-Source Elm SPA for a real world example of implementing an Elm frontend for an already available backend.
Elm is purely the front-end, so you won't need any php to create html code.
It provides broad coverage of standard HTML, but excludes service workers and some other modern web APIs - you can use javascript through Elm's foreign function interface (called Ports).
Elm has out of the box support for json from a REST environment, and powerful parsers if you need to use something else (e.g. xml). As Peter suggest, you might want to use a functional backend, but there is absolutely no necessity (I've Elixir and Node with success to date).
This is a question about designing API for frontend components.
For example: If there is any change in Model field in the backend then how can I propagate the same in frontend without changing anything else except model definition with additional field, in loosely coupled backend and frontend
And few more questions come in the same sequence are::
Will the suggested pattern work for the big project?
Is it a scalable solution for API driven micro-services based project?
Will there be conflicts if there are multiple teams working on this kind of project?
Is it good to cache APIs which are mostly frontend component definitions?