Hacker News new | past | comments | ask | show | jobs | submit login

Have to do some clarification here on the point of "Unclear architectural patterns", as the article is way too misleading.

- The reason the API call is made at `created` lifecycle is that the video is a quick, 5 minute intro for beginners. Beginners, as in "people who are familiar building static websites using html/css/js". There is no need to bring in Vuex or vue-router yet. In fact the whole beginner example can be put into a single HTML file by including a Vue script tag. The approachability is what made Vue shine. Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work.

> To answer to my initial question: API logic should not be written in Vuex nor in components. There is even a good example on how do that in some of the official code examples.

- The example[0] clearly has the API logic in the Actions. The `/api` folder is a mocked API for illustration purpose.

[0]: https://github.com/vuejs/vuex/blob/dev/examples/shopping-car...




>Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work.

Okay, say I do the tutorial and build a simple page - how hard is it to retrofit routing or whatever to it? A lot of the time with new frameworks, if I get past the initial setup hurdle, I can't work out how to easily move away from toy apps to something I can use in production.


One thing I want to say is: Don't assume only developers make websites. Don't assume everyone wants to ship a heavy and complex SPA.

Example 1: A great typographer, Wenting Zhang, author of Type Detail[0], contributing to Source Han Serif, learning Vue to do some interactive widget for variable fonts[1].

Example 2: Brian Terlson on TC39. He's using Vue without Vuex or Vue-router to build an app to track TC39 discussions[2].

I hope we can admit that many people might not need store and router[3]. Store and Router are necessary for building complex SPA, but don't make them necessary, as many don't want complex SPA. They impose learning efforts in exchange of better architecture, but the imposed effort might not be worth it for many people who just want some data-rendering, some reactivity and some interactivity on their websites.

[0]: http://typedetail.com

[1]: https://twitter.com/DesignJokes/status/1015003288528400386 and https://twitter.com/DesignJokes/status/1014260361535647744

[2]: https://twitter.com/bterlson/status/913433979239436293 and https://github.com/bterlson/tcq

[3]: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...


Thank you! That's a really good way to think about things and might be the push I needed.


This will probably be downvoted but I have come to appreciate frameworks which are opinionated and target a specific use case than very general and trying to please everyone.


AFAIK, with vue-cli 3.0 (that now includes a browser GUI) you can just add plugins to your existing project, and a router plugin should exist.

Previously on vue-cli 2.x, it was just a question on the project initialization step.


I'm not sure were the author looked for information about architectural patterns but there is a separate section on it in the documentation: https://vuex.vuejs.org/guide/structure.html

This clearly outlines a suggested structure for non-trivial apps, where API requests are separated from the state management. It also references the Shopping cart example as a guide.

Due to this glaring oversight I can't see any criticism the author has as valid in the section about "Unclear architectural patterns".




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: