Some questions / comments about project setup / usage

[vedmant]

@ezl

Questions

1. What's the github branches flow? Usually I create a branch for each issue and create pull requests when each issue is done. Is there some branches names convention? If no I'd suggest to create branches like "issue/323_short_descr".
2. How do I login to the local app? It sends link to email but it's pointing to remote dev server. I can login replacing url by localhost, is this usual way how this should be done on local or there is some simpler way?

Comments

1. I added *.env files to gitignore as they were not ignored by default (excluding example.env)
2. I see that this.$store is used in components, it's much cleaner to use mapActions, mapMutations, so on instead, it's recommended practice by Vuex. Can I refactor this while working on component?
3. I also see that Vuex is almost not utilized, most of the state is in components, it might be better practice to use Vuex for all data.
4. I see there are lots of es-lint and prettier errors, probably makes sense to fix them to keep code consistent.

I may add more questions / comments here later.

[aldarund]

q 1 - no branch conventions name, doesn't really matter much as branches should be deleted after merge.. Yes, create a separate PR for each issue. 2 - yes it is a way. backend don't really know who is sending it so we either pass it as param to backend which isn't much of secure, which could be again worked around but replacing just easier at right now than implementing anything other

comments 1 - example.env SHOULD be in repository. that's exactly what its for, example of env var to get project working 2 - where its recommended? https://vuex.vuejs.org/guide/actions.html

You can dispatch actions in components with this.$store.dispatch('xxx'), or use the mapActions helper which maps component methods to store.dispatch calls (requires root store injection):

Dont see much of benefits here, only if it used in several places in one file. And for example lets look at vue storefront. https://github.com/DivanteLtd/vue-storefront/search?q=%24store.dispatch&unscoped_q=%24store.dispatch pretty much store.dispatch used everywhere. 3 - why its better? If data is only needed in that component why should using vuex be better for it? Just for the sake of using vuex? 4 - yes, its @ezl some recent coding, no puns :) Need to add husky to prevent this :)

[vedmant]

@aldarund

Thanks for answers, few things:

2 - yes it is a way. backend don't really know who is sending it so we either pass it as param to backend which isn't much of secure, which could be again worked around but replacing just easier at right now than implementing anything other

Maybe just for development we can pass local URL to backend so it can send correct link? Cause I'm already seeing how this will bother me each time I need to login. For me this kind of small details are actually important.

1 - example.env SHOULD be in repository. that's exactly what its for, example of env var to get project working

I mentioned that I added ignore for *.env excluding example.env. Means all other .env files will be ignored but not example.env.

2 - where its recommended?

You can see every page in Core Concepts pages they have separate section for "The mapState Helper", "The mapGetters Helper", so on, using "this.$store" is a simple but dirty way of accessing store. There were no documentation about mapping helpers on each page if it was not the best way to do this. It's also much cleared to use map helpers, isn't clean code better than dirty code?

3 - why its better? If data is only needed in that component why should using vuex be better for it? Just for the sake of using vuex?

Ok, I can explain why exactly Vuex is better. Firstly, Vuex means that all the sate in one place, so everything is structured much better and consistently. Secondly, It's much better for debugging, it allows time travel, a way to see every mutations and what actually happens with the state, it's not possible with component state. Thirdly, when navigating between pages and components it often doesn't require to reload the state from backend every time, so it's much faster and reduces API load. Like some lists, currently if you go to other page, then go back each time you hit API and wait for the data, if last data was loaded just few minutes ago it doesn't require reloading. And in general app will be more robust and cleaner, if most of the state is separated from components, it will reduce components code and make them leaner.

4 - yes, its @ezl some recent coding, no puns :) Need to add husky to prevent this :)

There is an option to overlay all this errors on the app screen and prevent successful complication, so it will be not possible to not to fix this errors before commit.

[vedmant]

Another question, I see .idea folder is not fully ignored. I see there is large ignore config for .idea that probably ignores everything, but still I'm getting error regarding some PyCharm module as I'm using PHPStorm right now. What's the point of keeping some settings in .idea? I usually ignore whole .idea folder.

[aldarund]

Maybe just for development we can pass local URL to backend so it can send correct link? Cause I'm already seeing how this will bother me each time I need to login. For me this kind of small details are actually important.

we don't have

I mentioned that I added ignore for *.env excluding example.env. Means all other .env files will be ignored but not example.env.

Ok. i misread it then, sorry

You can see every page in Core Concepts pages they have separate section for "The mapState Helper", "The mapGetters Helper", so on, using "this.$store" is a simple but dirty way of accessing store. There were no documentation about mapping helpers on each page if it was not the best way to do this. It's also much cleared to use map helpers, isn't clean code better than dirty code?

I don't see how its cleaner and better. And I totally don't see how the existence of mapstate and mapGetters make $store is dirty way. If there is utility available than obv there will be doc for it, but it doesn't mean its recommended way. Its flawed logic. I dont see how using mapactions etc always make code not dirty. As I said you can lookup some large projects on github build in vue and a lot of them use store.dispatch etc.

Another question, I see .idea folder is not fully ignored. I see there is large ignore config for .idea that probably ignores everything, but still I'm getting error regarding some PyCharm module as I'm using PHPStorm right now. What's the point of keeping some settings in .idea? I usually ignore whole .idea folder.

its generated ignore file. And it as I see contains just .idea too .gitignore:25

Thirdly, when navigating between pages and components it often doesn't require to reload the state from backend every time, so it's much faster and reduces API load. Like some lists, currently if you go to other page, then go back each time you hit API and wait for the data, if last data was loaded just few minutes ago it doesn't require reloading

And it will means stale data - let it be stale, easily get out of sync and will lead to problems. And solving this really not trivial.

Secondly, It's much better for debugging, it allows time travel, a way to see every mutations and what actually happens with the state, it's not possible with component state

Just adding whole layer for sake of debugging doesn't sound good for me.

, Vuex means that all the sate in one place, so everything is structured much better and consistently.

And it means that components and pages are not isolated. Imo vuex should be used when you need it e.g. for communicating with different component, storing global data etc. Not just use it because its possible.

And in general app will be more robust and cleaner, if most of the state is separated from components, it will reduce components code and make them leaner.

And it will make heavier global component that whole app rely at and that is used everywhere instead of isolated use of data in components

[vedmant]

we don't have

Yes, I see that you don't have it, I mean to make something to simplify login while developing. Cause when I tested yesterday I had to login and logout dozen times.

I don't see how its cleaner and better. And I totally don't see how the existence of mapstate and mapGetters make $store is dirty way. If there is utility available than obv there will be doc for it, but it doesn't mean its recommended way. Its flawed logic. I dont see how using mapactions etc always make code not dirty. As I said you can lookup some large projects on github build in vue and a lot of them use store.dispatch etc.

Probably this is more of personal preference, but I see code with map helpers cleaner to use this.user than this.@store.state.auth.user when mapState is used, the same with actions / mutations / getters. Also since I started with React and Redux, mapping state to props is the best practice with Redux. As a summary I'd prefer using map helpers in my code.

its generated ignore file. And it as I see contains just .idea too .gitignore:25

.idea folder is still committed to the repo, I can delete it, but it might then delete your .idea if you pull changes

And it will means stale data - let it be stale, easily get out of sync and will lead to problems. And solving this really not trivial.

It's not stale, it's global state, the whole point of it is that it's global and not deleted after component unmounted. It can have loaded_at timestamp and reloaded after some time. Even if there is some bug related to the state it will be easy to see where it comes from as you can see every state mutation, state before mutation, state after mutation, in Vuex is done appropriately you can time travel, just replay state mutations step by step and see all the changes happening on the page. This debugging feature are really helpful especially when app becomes more complex.

Just adding whole layer for sake of debugging doesn't sound good for me.

Maybe for very simple app it doesn't make sense to use Vuex, but it's very helpful when app becomes somewhat more complex. Don't underestimate importance of proper debugging, it firstly saves a lot of time, secondly it improves quality of the app as you can get much more insights of what actually happed under the hood.

And it means that components and pages are not isolated. Imo vuex should be used when you need it e.g. for communicating with different component, storing global data etc. Not just use it because its possible.

Not sure what do you mean about isolated components, but if you need to communicate beetween components they are already not isolated. The whole point of Vuex is the ability to have whole global state in one place, that's not mutable. If we don't really need Vuex in the app, then it makes more sense to put this to global component and get rid of Vuex completely and remove extra dependency.

And it will make heavier global component that whole app rely at and that is used everywhere instead of isolated use of data in components

State is separate from components, the state size can never be that large to affect page performance, unless you add something crazy to that state, but it will be the same with component state then. If you care that much about memory optimization, state can be cleaned up on component unmount (if there is no need for that data later).

As for me it's much better to have things in one place than when they are scattered around components. Also ability to use great dev tools is very important. I'm not telling that there is need to redo things that are done now, but if I started a new app I'd put most of the state in Vuex.

[ezl]

weighing in a little bit:

eslint errors

oops sorry. my fault. will be better in future.

login/logout

i'm in favor of making dev easier.

2 thoughts:

1. we are rarely doing a lot of login/logout even during dev, but there are cases that we do. IMO it's question of balancing whether it's worth investing the effort to make it easy for the minority of times that we will need to do this.

2. The other question is whether it will stay sufficiently close to the actual production case so that we won't have to keep maintaining / updating this method of massing a local URL to the backend. if our dev environment diverges too much from the production one, it might make dev easier, but it increases errors that we don't detect when we think we have a working version locally that won't work in production. overall though, i'm in favor of making dev easier, so @vedmant if you want to take this on, as long as @aldarund doesn't object, go for it.

other stuff -- you 2 decide.

[aldarund]

It's not stale, it's global state, the whole point of it is that it's global and not deleted after component unmounted

It will be stale . E.g. if user just hit page - and if there something changed instead we will give him old data. Which is issue. and its not trivial to solve

It can have loaded_at timestamp and reloaded after some time

And before that time user is stuck with old data that is out of sync with backend. or he need to reload whole page. Not good. Thats exactly what I mean that this kind of global state isn't trivial and acts like cache

[aldarund]

Maybe for very simple app it doesn't make sense to use Vuex, but it's very helpful when app becomes somewhat more complex. Don't underestimate importance of proper debugging, it firstly saves a lot of time, secondly it improves quality of the app as you can get much more insights of what actually happed under the hood.

And you can also easily debug components itself because they are local and isolated so you see what happens exactly in it. So its double edge sword

[aldarund]

Not sure what do you mean about isolated components, but if you need to communicate beetween components they are already not isolated

it means that if data shouldn't be shared between distant components that using vuex usually not worth it

[aldarund]

State is separate from components, the state size can never be that large to affect page performance, unless you add something crazy to that state, but it will be the same with component state then

I neve said anything about perf. Im saying about code. Putting all in vuex is like putting all into global state while it only used in one local place. And it will lead that vuex become really big and instead of just looking into code of component you will end up looking into component and vuex every time

[vedmant]

It will be stale . E.g. if user just hit page - and if there something changed instead we will give him old data. Which is issue. and its not trivial to solve

It's actually very trivial to resolve, if you want to make sure you are getting new data every time component mounts, just fetch it on mount. Using Vuex even better in this case, it will render page instantly but with previous data, will show loading indicator and update data if it changed, so UX will be much more snappier, as user will not need to wait and look on placeholders or loaders while data is loading, page shows useful info instantly if it's opened second time.

And before that time user is stuck with old data that is out of sync with backend. or he need to reload whole page. Not good. Thats exactly what I mean that this kind of global state isn't trivial and acts like cache

No need to reload whole page, there are two choices, reload data on mount, or reload data if it's deprecated also it's easy to add refresh button on the page for manual refresh. In any case this is only doable with Vuex.

And you can also easily debug components itself because they are local and isolated so you see what happens exactly in it. So its double edge sword

You can't time travel or see every mutation with component's data debugging.

it means that if data shouldn't be shared between distant components that using vuex usually not worth it

Still better to have it in one place for simpler debugging, also for all the vuex debugging tools.

I neve said anything about perf. Im saying about code. Putting all in vuex is like putting all into global state while it only used in one local place.

Properly organized state will be simple to navigate even if it's really large.

And it will lead that vuex become really big and instead of just looking into code of component you will end up looking into component and vuex every time

It's simpler to look into two separate smaller files that have own purpose than into one large file where everything is mixed together, that's common best practice to separate code into files.