Edit: The original title of this gist was "Vue from scratch" but soon (actually from the very initial stage) it took the road of "CakePHP and Vue as monorepo". This still contains almost all the Vue specific items as listed below (the 18-point list is not changed, although some of the items are skipped or have notes added in comments). This is a fairly large piece of text + screenshots (to read and see) but not really time consuming to implement (that's what I tell myself, anyway). Happy reading.... caking and vueing... cakueing perhaps!
Thanks to github.com/pankajvashisht-ucreate for the list
Following is the original 18-point list shared by Pankaj Vashisht for someone who is starting in Vue.js from scratch
- Node installation
- Initialization of package.json file
- Basic understanding of script key in package.json file
- Install vuejs
- Vue file initialization with vue instance
- Understanding of vue.use methods
- Vue router
- Vue lifecycle (Hooks)
- Design Pattern
- How to create component in the vuejs
- Vue html Attributes (Very Important)
- Two way binding
- Data pass parent to child and child to parent (Props)
- Understanding the concept of $emit in the vue js
- Vue js slot
- Vue js Object keys in details
- VueStore for data sharing
- How deploy the Vue js App
There are other ways of handling mono-repo and, obviously, very different ways of handling separate front-end repo (for Vue).
The "thing" (I wouldn't say it is a "good" or "bad" thing - just a thing) is that with the setup like this the compiled files will always be part of the commit - whenever there would be a change in Vue source code, the compiled files will change and will become part of the commit.
The way I keep the back-end/front-end commits separate is that when I know I am doing something for the API or at CakePHP level, I commit after making the changes (not necessarily
push
- unless required, of course), and when I am doing changes in the front-end code (Vue source code), after the changes are done I commit thewebroot/vue
folder (and the included files) - again, not necessarilypush
.push
is done when the version working on localhost works like it is supposed to work - this ensures that the code stays separate for FE/BE at least at a per-commit level. 1 commit should have either BE code or FE code, but not both, and it is "OK" (and in fact it makes more sense) that the commits that are related (even if the commits belong to BE and FE separately) should bepushed
at the same time.