181–190 of 382 posts
This is going to be a drop in the ocean but Vue is the bomb! It made perfect sense, and that's a big compliment for a framework. For me personally it took the MVC into SPA territory, got rid of all the muck that's jQuery and replaced it with a fun, easy to design UIs with platform. If you ask me it's biggest achievement is that it put design, experience and interaction on the same level, literally - thanks to .Vue fi…
Earlier quoted context omitted.
> I am never a fan of two way data binding as an alternative. The author is wrong. Vue doesn't have two-way binding. It has one-way binding with events. Components can't force anything upon their parent's state with an event.
I mean, Vue calls it two-way data binding. From their website: > "You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases." I'm not knowledgeable eno…
All props form a one-way-down binding between
the child property and the parent one: when the
parent property updates, it will flow down to
the child, but not the other way around. This
prevents child components from accidentally
mutating the parent’s state, which can make
your app’s data flow harder to understand.
AngularJS uses two-way binding between scopes,
while Vue enforces a one-way data flow between
components. This makes the flow of data easier
to reason about in non-trivial applications.
Earlier quoted context omitted.
Our company used React when starting a new project, but we still had an existing project with a vanilla HTML/CSS/js website, which really needed a rewrite. I had a talk with my cofounder about the strengths and value of React, but hadn't dived deep yet - I wasn't working actively in the codebase of the new project. I tried to, and all the moving parts were monstrous to wrap my head around - states, redux, actions, wh…
You're talking about Redux, not React. Your website would have probably been fine with just React. React gives you the choice to avoid needless frameworks and choose the level of abstraction that best fits your project.
For example, JSX is an abstraction level I'd like to use. It requires an npm install to set up to contribute to production code. It has already crossed the threshold of an easy on-ramp for say, an intern -- because if this involves a first-time npm set-up on their machine, there goes the rest of the week.
With Vue to start using another feature/abstraction layer, you never have to do additional setup (your html file includes the vuejs script already), you just read the syntax docs and get going.
Additionally, React (and redux even more, yes) involves much more boilerplate than Vue does for every new feature you want to use, which is often more verbose/obtuse and hard to parse for a junior web developer.
Earlier quoted context omitted.
You're talking about Redux, not React. Your website would have probably been fine with just React. React gives you the choice to avoid needless frameworks and choose the level of abstraction that best fits your project.
Nope, I'm talking about react. I'm aware redux is just another step in the "level of abstraction you may want to use". And the problem is that every level you want is a challenge to get started with in React. For example, JSX is an abstraction level I'd like to use. It requires an npm install to set up to contribute to production code. It has already crossed the threshold of an easy on-ramp for say, an intern -- beca…
I tried nuxt (a vue framework) the other day and was disappointed. It seemed like a very straightforward way to create a UI over a REST backend, but I kept getting stuck with the issue of how to have a clean separation of the back end and front end responsibilities. For example, I wanted to have a UI that was rendered based on the JSON payload that would get committed to a Vue Store. I consistently ran into issues wh…
Strapi just released their tutorial on nuxt and other backend stuff. https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-v...
I want to be able to have essentially have everything server rendered with reactive views. Not sure if there is anything that supports that, but I feel like that's how a SPA "should" work to an extent.
Also, what gets really weird is if you are trying to use environmental variables. The solution is to inject your environmental variables into the client (https://nuxtjs.org/api/configuration-env/) which is what I want to avoid.
I can do what I want to an extent with Ruby and Sinatra, I just want to avoid setting up webpack and babel for getting the reactive components.
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…
> Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, and isn't just idyllic, agnostic "data". Things like "is this menu open or closed? The entire UI is specific to the UI. Trying to separate "entities" or "server data" from "UI concerns" is IMO a waste of time and just confusing. At the end of the day, you have a state tree, and you project it to a UI. Where…
In fact, the reason we have the particular toolbox of standard GUI elements that we have these days is precisely because they serve different use-cases. Each serves a particular one, and the reason it's survived is because it isn't made redundant by any of the others.
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…
The claim isn't that there's no cargo cult around the React ecosystem — but not everyone writing React code is approaching it with experience, which means they try to pick up best practices from other people. That's not "cargo culting"; it's a reasonable thing to do when you have to solve a problem you don't know how to solve!
Ultimately, people aren't being "tricked" into using these tools. They proliferate because they solve real problems people have, and a lot of people would rather work with a popular and well-documented solution (with known advantages and drawbacks) than trying to forge their own path and seeing how it goes.
Oh? I've only ever been in the gitter room... I had no idea there was a discord too...
We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works. TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen. There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design v…
vue 3 will be entirely rewritten in typescript. https://github.com/vuejs/roadmap