I am writing a to-do list and I want to keep it simple. Its a PWA in Vue.
JS: I am using
- Vue router
- Vuex
- indexdb
- Vue
- Typescript
CSS: I am using
- scss no framework very targeted css
- mobile only targeted app
There is little more to say on that front, on the test side we have Jest and acceptance tests ran by puppeteer wrapped in Jest.
Should I use local storage? There is one limitation I want to do but cant if using this route, quickly create and throw away multiple lists and persist without serialisation. Why? It just seems easier and more efficient than messing around with storing a massive string, localStorage was not really designed for storing json, thats why indexdb exists, plus a table per list and a row per item and all that. Am I just going too far?
Top comments (12)
I'd also add that I am not convinced that Vuex is right. I have to create lists and items, remove lists and items and if you imagine an item is scoped to its list, does anyone really need to know about each other. But then again I don't like props at all, not one but. They should be used for differentiation between components in my book, not a means to pass data along. But vuex moves us back to centralisation (is that bad). I can't decide.
I have the feeling Vuex can be hijacked for things it has not been designed to.
If you do not need to manipulate a data you have created in your component, do not use Vuex, it will be simpler to manage it in the component itself.
That being said... I have the tendency to use it for every state mutations. Like even if this is not necessary. I just like the action / mutations / getters split. It makes my code so clean.
Just a question of taste I guess. What is great with Vue is that it will work even if you do not use Vuex.
À other tips, if you are more an MVC guy, take a look at VuexORM 😉
I have the same tendency, Vue become UI logic only and business logic is just in one place, it sounds so appealing. But I had a think, if I really want centralisation I could use the root state of my app, it certainly makes things clearer what is local to my component and what is global.
I have to say state management responsibilities are so very confusing in modern JavaScript!
Flux pattern is not intuitive, mostly from the point of view of people like us used to classic one way MVC I admit.
Like they said,
And I think this is brilliantly said, because it should just make sense to you or you should not use it because it would become less productive than without.
In the end, like you said it is very suitable for architectures where you have a good separation between your UI (Vue) and your business (whatever server side programming language that serves data via a REST/GraphQL API) 😉
I've used vuex for less. I usually only use local storage if I need to persist between a refresh
Overengineering is my biggest fear in development, the problem was introduced to me when I first started development at Dyson, I take it very seriously. I took vuex out to find alternatives
This sounds good. You might want to look into "trusted web activities". It sounds like you are building a mobile only app. And in that case, having the ability to publish it on the play store might be interesting.
Why am I mentioning it: because there are some restrictions that might render indexedb as not the ideal candidate. As far as I understand, data access must be implemented differently. But I haven't looked into it enough. I might be wrong.
I actually started the project going down the Cordova route but I think that's later down the line, for now it's just a proof of concept I guess. I'm going to use pouchdb for indexdb and look at swapping that out later.
It sounds fairly straightforward for a PWA. Not sure you need Vuex or even the Router for a todo list, though.
Based on this I am moving to root state + local component state and have removed the router. Thanks for the feedback.
Instead of vuex suggest to use Observable for simple global state.
vuedose.tips/tips/creating-a-store...
I have found something more suitable and built in to Vue. Provide, inject. This allows DI from a component to descendents. My App component is now a fundamentally a store as well. But because provide is not reactive it does mention passing observables. But there again I don't have a lot of data that needs to be reactive.