Vue.js: the good, the meh, and the ugly • Hacker News Board

Re: Vue.js: the good, the meh, and the ugly

#191

Post by _bxg1 » Fri, Jul 06, 2018, 4:26 AM UTC

danwilsonthomas wrote: post #149

_bxg1 wrote: post #106

Earlier quoted context omitted.

Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function). So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store). Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, an…

I've seen this idea a lot from members of my team that when you use a state management library then absolutely everything has to go through that state management library. This results in some of that pain you describe with state that's specific to the UI. If you're still working with React, try keeping that menu or input state in the component with setState instead of putting it in the global state store. I've found…

That seems like a good approach. Still, it doesn't seem like the rendering code or the Store code could ever really be worked with in isolation. As I said above, picking a coupling boundary is like picking a poison. They all seem to suck for different reasons; I just personally tend to choose component boundaries.

Re: Vue.js: the good, the meh, and the ugly

#192

Post by philliphaydon » Fri, Jul 06, 2018, 4:36 AM UTC

pier25 wrote: post #60

Tade0 wrote: post #53

>To answer to my initial question: API logic should not be written in Vuex nor in components. There is even a good example on how do that in some of the official code examples. Ok, but where's an example that shows how this backfires? Why should the API logic not be written in Vuex? One more thing I think deserves mention: Vuetify - Vue's material design component set. It's being used in the project I'm currently in…

> Ok, but where's an example that shows how this backfires? Why should the API logic not be written in Vuex? (Author here. I didn't really expand on that because the article was getting pretty long already.) For example, think about authentication logic. It involves more than just calling the API. Eg: extracting the JWT, saving it to localStorage, decoding it, maybe checking user roles, etc. If you do that kind of lo…

I use vuex with namespaced modules, but then those modules just call out to abstracted implementations if it's more than just http request. So for example with auth, I have a vuex auth module.

It then has some getters which just get the state from the store, but the actions call to a separate module which manages storing it in LocalStorage or making the http requests.

Works for me, but I just took what I learned (Vue) moved it to when I learned a year later (Vuex), when things became complicated in Vuex I just moved the complicated bits back 1 bit more and everything became simple again (which seemed like the logical thing to do).

Re: Vue.js: the good, the meh, and the ugly

#193

Post by philliphaydon » Fri, Jul 06, 2018, 4:39 AM UTC

jorblumesea wrote: post #130

One of the best arguments against Vue is typescript support. React has really good support for it, even for the state libs like Mobx/Redux etc. Until they turn that around it will be hard for any frontend application to scale properly. I think Vue is great for smaller projects and would absolutely recommend it.

TypeScript works fine?!?!? With @vue/cli it's trivial to setup, it's literally option in a new app.

Vue 3 they are moving to TypeScript:

> Will be using TypeScript. For internal implementation only. Does NOT affect ES users, but should improve TS integration for TS users.

https://github.com/vuejs/roadmap#3x

Re: Vue.js: the good, the meh, and the ugly

#194

Post by calgaryeng » Fri, Jul 06, 2018, 4:44 AM UTC

jazoom wrote: post #117

RussianCow wrote: post #114

Earlier quoted context omitted.

Sorry, you are correct, I made that assumption. It seemed implied by your use of user complaints as a metric of success—I assumed that was the case because you didn't have hard data, so I apologize if that's not the case.

Not a problem at all. I place high value on being available to users of my website. I reply to each and every message. Perhaps it's a bit unusual for someone to talk about that before the numbers. It has been my experience that I've gained more valuable insight from talking with users than I have from the numbers. But, as a little Latina girl once said, why not both?

I think the other person was talking about quantitative data (e.g. from Google Analytics), not qualitative data from customer conversations / complaints.

Re: Vue.js: the good, the meh, and the ugly

#195

Post by zubairq » Fri, Jul 06, 2018, 4:44 AM UTC

I used React for 3 years but once I discovered Vue I switched. The reason is that React and Vue have different audiences. Vue is more for people who don't think in code whereas I think tht React is more for "Hard Core Developers", so I chose Vue for a Javascript development platform that I built

Re: Vue.js: the good, the meh, and the ugly

#196

Post by jazoom » Fri, Jul 06, 2018, 4:52 AM UTC

calgaryeng wrote: post #194

jazoom wrote: post #117

Earlier quoted context omitted.

Not a problem at all. I place high value on being available to users of my website. I reply to each and every message. Perhaps it's a bit unusual for someone to talk about that before the numbers. It has been my experience that I've gained more valuable insight from talking with users than I have from the numbers. But, as a little Latina girl once said, why not both?

I think the other person was talking about quantitative data (e.g. from Google Analytics), not qualitative data from customer conversations / complaints.

Yes. That's also what I thought. I'm not sure why you think I thought otherwise.

Re: Vue.js: the good, the meh, and the ugly

#197

Post by strken » Fri, Jul 06, 2018, 4:55 AM UTC

acemarke wrote: post #170

strken wrote: post #168

Earlier quoted context omitted.

This is all absolutely true! Redux and React-Redux, and their associated documentation make a lot of intelligent design tradeoffs that have a lot of thought put into them, and that's worthy of respect. "Overengineered" was too strong a term, and I shouldn't have used it. Sorry. However, some of the things that have been traded are default configuration that represents typical use, standardisation across the ecosystem…

Yeah, for a while it seemed like there was a new Redux side effects lib coming out every week. At this point, though, it's pretty much standardized on thunks for basic use cases, and either sagas or observables for more advanced use cases based on your preference of writing async logic. > What I've taken to doing is exporting a dispatch function that calls the store's dispatch, not the store. Not sure I follow that t…

> Not sure I follow that train of thought - could you point to an example?

Something like

  const store = createStore(...)
  export const dispatch = (action) => store.dispatch(action)

It removes the temptation to read directly from the store.

> `redux` and `react-redux` are deliberately separate packages

Yeah, my bad, got the import wrong.

> ...limits the reusability of your logic...

When would this become a problem, in practice? Reusable actions across different react/react-native UI, or multiple apps? Switching between user accounts? How common a use case is it?

Even if this is a constraint, I'm of two minds about whether a hack in isolation is worse than more complicated action boilerplate in general.

> ...and also makes it a lot harder to test...

This can be mitigated by Jest's mocks.

> https://github.com/markerikson/redux-starter-kit

That's really good. Unfortunately, it's not the same thing as bundling it with Redux proper.

Anyway, thanks for engaging with me. I never intended to do a deep dive into Redux's design, only to sympathise with stupidcar's comments about third-party state management, but it's interesting to hear the perspective of a maintainer.

Re: Vue.js: the good, the meh, and the ugly

#198

Post by blencdr » Fri, Jul 06, 2018, 4:57 AM UTC

sheeshkebab wrote: post #190

heisenbergs wrote: post #50

Earlier quoted context omitted.

vue 3 will be entirely rewritten in typescript. https://github.com/vuejs/roadmap

And that will probably be the end of vue...

have you even tried to use TypeScript on a real project to say something like that ?

Re: Vue.js: the good, the meh, and the ugly

#199

Post by sbjs » Fri, Jul 06, 2018, 5:00 AM UTC

ilovecaching wrote: post #2

I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…

Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language.

React is just JavaScript and HTML.

Re: Vue.js: the good, the meh, and the ugly

#200

Post by _hardwaregeek » Fri, Jul 06, 2018, 5:14 AM UTC

allover wrote: post #113

atombender wrote: post #97

Earlier quoted context omitted.

There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise s…

But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community. Can you really look at where the community is, the perception that still exists that React+Redux is necessary, project…

Could you provide a source for the maintainers of redux-form admitting that Redux was a poor fit for forms? I'm inclined to agree and am kind of interested to see their reasons.