Create library for later use in Quasar project
-
Hi All,
I am about to start work on my first Quasar app after doing a bunch of reading and learning on the framework and its technologies. Being newish to javascript, web development and mobile (but not to software engineering) this has taken some time, but now I feel ready!
My application will be data driven, and my goal is to store all data in the cloud, for example with Firebase. I would like to abstract the data logic from the front end application by creating a javascript library that I can import into the quasar application.
I wish to do this for the usual reasons - to decouple the logic from the UI, automation of testing, use of different developers for the parts (there’s a couple of us on the project), etc.
How do you recommend I approach this? Is this the recommended way? It’s been so programmed into me that this is standard convention in my field, I want to check and ask how other do this before I jump too far in.
Many Thanks!
Griffy
-
For sure, SoC and SRP are both key in any programming situation.
I would like to abstract the data logic from the front end application by creating a javascript library that I can import into the quasar application.
Before you get to working on the abstraction of logic, did you look into reactive programming in general and understand how Vue works within this paradigm? Also, do you understand how you get SRP for the UI with Single File Components?
Scott
-
Hi Scott,
I had to Google the SoC and SRP terms, but they’re essentially the same principles as I’m used to.
A year or so ago, I had started to pick up React and ended up dropping it due to life things getting in the way. I first got a look into reactive concepts there. When picking it back up, as I wasn’t sold on React, I started looking around some more and that’s how I found Vue, and subsequently React.
I liked Vue and Quasar right away, but instead of jumping straight in I recently finished Danny Collin’s Udemy course in its entirety (almost… I didn’t do the final section on building the different platform apps). Of course, have also been exploring the forums and other online material too.
Concerning single file components, we explored it in the Udemy course. I’m someone who naturally struggles with large code files anyway, so this immediately suits me and is typically how I work - DRY and a good amount of decomposition. I’m sure I’ll make some missteps along the way, but that’s part of the learning experience I guess.
So, yes I feel I have some understanding on Reactive concepts and single file components and feel somewhat ready did dip my toes in. It’s how I’ve always learned the best.
Thanks,
Griffy
-
Ok. If you went through Danny’s course, you have a got bit of the basics. So, what there is with Vuex are modules. Quasar sets you up directly with that. Then it is a matter of whatever else you intend to build and thus need. One other thing you might want to look into is GraphQL. It is a step above REST APIs (IMHO) and when done right, simplifies syncing state and data with the server. Firebase, I believe, doesn’t support GraphQL directly though. At any rate, if you run into troubles with Quasar, we are here.
Scott
-
Ok, gothca.
So I was imagning this scenario where I would create a pure Javascript library that I could then include in my project and call it from Quasar using a set API.
But what I understand from you, is that I should wrap all my custom logic in Vuex modules as that provides me with an extension of sorts of the State.
-
Yeah, well, state and state transitions in the UI takes place (for larger projects) within Vuex. State that is component level only can stay within the component. You need to make those decisions. Some of those things can be considered reusable code and modularized outside of Vue and Vuex too. And, with Vue 3 coming along, it can be done even better. But, yeah. Vuex modules is a good start to modularizing your state management.
Scott
