This is about the only place I would choose Vue over React is when I'm enhancing an existing, mostly static site/app. I feel the story is a lot better here for Vue. On the flip side, I find that for entire applications, I like React much better than everything else.
cute...
I have a relatively limited set of plugins I use though, and this is unlikely to make it onto the list. Would suggest, if you are considering it, to audit the code and the dependency code, then dev install.
Not saying this is a bad extension, only that with all that has come to light recently on plugins, trust is limited.
"React's use of JSX results in a steeper learning curve as you must learn this on top of familiarizing yourself with the library."
I cannot disagree more... JSX is an XML syntax mostly similar to html in it's lowest common denominator + JavaScript. For someone who should be familiar with JS and HTML going in, JSX is much less of a learning curve than a specific rendering DSL like Angular or others in practice.
The co-mingling of your component markup into your component JS is harder for those locked into a certain mindset to change, that does not make it harder conceptually.
Aside: materal-ui is the single nicest component library I have ever used in 24 years of working on web based applications. I've seen and used a *LOT* of tools and frameworks over the years. React + Material-UI feels right to me.
This is getting very cool... when I first looked at GraphQL a few years ago, the tooling was much less mature and took a lot of effort. It seems to be getting much better to use in practice. Would still like to see more articles about how to attach/handle security (jwt bearer tokens, for example) with a GraphQL server and client.
On #2, when using a getter that calls a function that can throw, it's a good idea to wrap in a try/catch as property getting should not be a point where an application throws in practice.
You could alternatively use the following pattern, and have your application loader parse and inject the configuration for the rest of your application to utilize...
export const configuration = {};
export function setConfiguration(data) {
Object.keys(configuration).forEach(c => {
delete configuration[c];
});
Object.assign(configuration, data);
};
export default configuration;
Not really code or JS centric and doesn't really dive into the issue at all with useful examples. It's a low quality post.
Personally, I'd say it depends... you should absolutely load middleware separate from your controllers. In terms of service separation, it depends. If it's a really simple DB call without much abstraction, I'd say do it in your controllers.
With koa, I add a database connection object to the context (context.db or context.sql) that makes it ready to go... this way I can use:
router.get('/foo/:id',
router.validate({
params: Joi.object({
id: ...
})
}),
router.authorize('admin'),
async ctx => {
ctx.body = await ctx.sql`
SELECT ...
FROM ...
WHERE Foo.id = ${ctx.params.id}
`;
},
);
I use koa router for all of my api routes, and mount it to `/api` at a higher level. I also add a validate and authorize function to the router. This way, I can add Joi validation schemas to body and/or params, etc. The authorize method inputs `(...roles)` so I can just add any required roles, if no role is specified, it still must have a logged in api token (jwt) with the request, but any role allowed.
In this case, separating out the sql query into a separate service or data access layer doesn't add value imho.
Just yesterday gave a quick training session on Async functions and Promises... One of the few times I've used typescript, only to reinforce that Async functions return a promise, and can await on promises, to show a function returning a promise is effectively the same. As well as Promise.resolve and Promise.reject for use in mocking for tests.
For pretty much everything I'm working on now, I cut off with fetch and async function support (around April 2017 and newer browsers). In node, I use node-fetch or setup a global if I'm sharing code libraries.
While fetch isn't perfect, usually create an api wrapper around it. It's standard, cleaner than alternatives and built into the browsers (smaller bundles).
On #2, when using a getter that calls a function that can throw, it's a good idea to wrap in a try/catch as property getting should not be a point where an application throws in practice. You could alternatively use the following pattern, and have your application loader parse and inject the configuration for the rest of your application to utilize... export const configuration = {}; export function setConfiguration(data) { Object.keys(configuration).forEach(c => { delete configuration[c]; }); Object.assign(configuration, data); }; export default configuration;Not really code or JS centric and doesn't really dive into the issue at all with useful examples. It's a low quality post. Personally, I'd say it depends... you should absolutely load middleware separate from your controllers. In terms of service separation, it depends. If it's a really simple DB call without much abstraction, I'd say do it in your controllers. With koa, I add a database connection object to the context (context.db or context.sql) that makes it ready to go... this way I can use: router.get('/foo/:id', router.validate({ params: Joi.object({ id: ... }) }), router.authorize('admin'), async ctx => { ctx.body = await ctx.sql` SELECT ... FROM ... WHERE Foo.id = ${ctx.params.id} `; }, ); I use koa router for all of my api routes, and mount it to `/api` at a higher level. I also add a validate and authorize function to the router. This way, I can add Joi validation schemas to body and/or params, etc. The authorize method inputs `(...roles)` so I can just add any required roles, if no role is specified, it still must have a logged in api token (jwt) with the request, but any role allowed. In this case, separating out the sql query into a separate service or data access layer doesn't add value imho.