search

davestewart / vuex-pathify

Vue / Vuex plugin providing a unified path syntax to Vuex stores
https://davestewart.github.io/vuex-pathify
MIT License
1.37k stars 57 forks source link

using @ vs . in subproperties access #84

Closed bkarlson closed 5 years ago

bkarlson commented 5 years ago

Pathify been hugely helpful, but due to its steep learning curve (for a beginner) I made a mistake in my early code and used getters like myTabs: get('uiStore/menuItems.myTabs') (note period as subproperty separator). To my surprise it worked fine and did not trigger any error or unwanted behavour.

Now I fixed it to myTabs: get('uiStore/menuItems@myTabs'), but trying to understand whether using . instead of @ is a bad practice here? As keeping . would be more traditional and obvious for less JS-seasoned coders in my team.

davestewart commented 5 years ago

Hey Benny,

Thanks for making the issue.

The subject of @ vs . for sub-properties is one of the more common questions I get asked.

Historically, I used @ to make it explicit that sub-properties were being accessed, because at the time of writing Pathify, Vuex was sort of the "Holy Idol" (for want of a better expression) that couldn't be touched. I didn't want to make it seem like I was "cheating" too much so I decided to make it explicit.

Technically, I honestly can't remember if I HAD to have some way to manually specify "I want to access sub-properties at THIS point in the path", though programatically, I do need to know where sub-properties start so I can handle them. It may be that in a future release I look to support dot properties in place of the @.

If you are interested, you can see the actual resolver code here:

https://github.com/davestewart/vuex-pathify/blob/master/src/services/resolver.js#L102-L163

As for the code seeming to work now, I would stick to the @ as I may decide to tighten this up.

In fact I started re-writing this a couple of months back when I added variable expansion support in paths because I realised there was some optimisation that could be built in by changing the function to a class.

So anyway, there's a bit of background for you. Feel free to ask more questions if you need to, and I'm glad it's proving useful for you and your team!