|
evilfunkyogi posted:JSX feels kinda wrong at first but declaring your templates in javascript has some cool side effects like being able to catch databinding issues at compile/transpile time instead of runtime. Yeah ng-build/npm run start-aot catches template errors, but sometimes the output isn't as detailed as it needs to be, its usually just poo poo at the end of NPM's error log and if you're even slightly new to Angular you'll have no idea what the gently caress it means. Sometimes the application compiles properly and only fails in the console log when you navigate to the template that its failing on. Another problem is if you're building an enterprise-level application in Angular, which is honestly what Angular is used for a lot right now -- your ng-build can sometimes take literally upwards of 10 minutes, so its 10 minutes to diagnose a template error. In retrospect Angular really could do error-handling better right now, especially considering we're on version loving 7. TypeScript on the other hand produces perfectly good errors which are usually caught right away when you save. Edit: I also don't HATE JSX as much as most Angular Devs seem to. But it can carry a risk of a complex component getting stuffed full of markup which I guess can start to look dirty. It also seems like it's common to insert logic directly into the JSX, like full loving functions right in there which I'm not wild about it's not that you can't do that in Angular, but you just wouldn't (sometimes you do for little things, but generally you don't.). Angular seems to have a stronger focus on abstraction, despite people going on about differentiating functional, state, and container components in React. Additionally Angular's template language can be confusing at first, admittedly, but once you get the hang of it you really understand how strong it really is. ngFor, ngIf, [property], (method) and [(shorthand)] bindings are all great. This doesn't even take into account the simple superiority of TypeScript in general. I get that you can use stuff like TS/MobX to build the same sorts of @Injectable() services in React and generally speaking a lot of people don't like DI but tbh TypeScript+RxJS is just the hottest god drat poo poo. Borderline Fanboy Footnote: A couple of the major arguments against choosing Angular over React are scheduled to be (hopefully) nullified once the Ivy Rendering Engine makes its way into release, where the application won't package unused libraries, will provide more succinct error reporting for template issues, and significantly reduce application load, rendering, and package resource costs. Ape Fist fucked around with this message at 23:15 on Sep 2, 2018 |
# ? Sep 2, 2018 20:16 |
|
|
# ? Jun 6, 2024 20:26 |
|
JSX rules eff the haters I maintain some AngularJS projects and directives in HTML are dumb and I hate them and hey now I'm doing some stuff in Vue for learning and I hate directives there too (I like a lot of Vue otherwise tho) map over v-for anyday I also cant remember when your JS and data and poo poo is in quotes and when its in braces and the mixture sucks A real answer about why I like React is that the majority of your logic is just JavaScript and functions and not goofy directives and binding
|
# ? Sep 3, 2018 04:36 |
|
Angular is fine. React is fine. They're both fine. Sometimes one is more fine for a specific project than the other. Sometimes a framework has something I don't think is fine. I don't do that thing. That's fine too. Sometimes I do something the framework doesn't like, but I like it, so it's fine. It largely depends on your point of Vue. Choices don't matter, all will be dust in the end, free will is an illusion.
|
# ? Sep 3, 2018 04:52 |
|
Not a direct answer to the question, and perhaps not a fair comparison, but React's integration of code logic, visual elements, and dynamic style feels much more natural than rendering templates in Django. I get why mixing HTML and code is unappealing to some people, but I personally love it; it feels more natural than flipping between multiple files. Ie organization by display item rather than by type of code. More controversial: I enjoy React's inline styles, and use them exclusively over CSS classes. I use CSS files only for setting overall defaults for each type of HTML element. Dominoes fucked around with this message at 05:20 on Sep 3, 2018 |
# ? Sep 3, 2018 05:16 |
|
my bony fealty posted:JSX rules eff the haters Switching from Angular 1.x to React was a beautiful experience
|
# ? Sep 3, 2018 05:50 |
|
Currently got tasked with setting up the front end for a greenfield react/redux project, coming from an angularjs project with no state management, it's been a pretty great experience. Also, Olive Branch has been pretty great working with an older Rails backend as a necessity. Recommended. ddiddles fucked around with this message at 07:22 on Sep 3, 2018 |
# ? Sep 3, 2018 07:19 |
|
I don't think anyone is going to defend AngularJS tbh.
|
# ? Sep 3, 2018 08:05 |
|
Tbf I'm very glad I have to maintain AngularJS stuff and not the likely alternative, jQuery spaghetti piled high. Seeing jQuery in AngularJS is weird and uncomfortable though. Was that a normal thing?
|
# ? Sep 4, 2018 15:21 |
|
React and Angular are both fine, but React speaks to me in a way that Angular never has. I like the template, styling, and sometimes logic all in one logical unit (at least I like the idea of it...there's still some churn on what the best way to do the styling is). Abstracting into a component is just a different type of abstraction then separating all your styling, logic, and templating. I would argue it's a better way of abstracting stuff. That being said, there are pitfalls to the approach. For example, you have to watch where you put your logic so you don't end up with an unmaintainable mess of spaghetti. Then again, there's pitfalls with every paradigm and I suppose the logic thing is a common pitfall in all sorts of ways of abstracting your poo poo. Right now I'm thinking of Django which strongly encourages no logic in your templates...you still have to make sure you carve your problems logic into views, classes, functions, tags that make sense. Anyway, regardless of whether you use Angular or React you're better off than you would be managing your DOM manually unless you're just creating simple applications!
|
# ? Sep 4, 2018 17:27 |
|
my bony fealty posted:Tbf I'm very glad I have to maintain AngularJS stuff and not the likely alternative, jQuery spaghetti piled high. that was one of the biggest weaknesses of angularjs, angularjs was dependent on jquery (or to be more accurate, a subset of jquery called jqLite, although it would use the included jquery if it was available). if you're wondering why the angular is faster than angularjs, well, that's one of the reasons.
|
# ? Sep 4, 2018 18:01 |
|
How the hot poo poo do I get the details of a DOM element in a child component in react? I'm rendering a <div> whose height might change based on its content and I'd like to pipe that particular number once rendered back up to the parent component? lets say I have ugh: code:
code:
|
# ? Sep 4, 2018 20:50 |
|
Ape Fist posted:How the hot poo poo do I get the details of a DOM element in a child component in react? Use a ref: code:
code:
https://reactjs.org/docs/react-component.html#componentdidmount https://reactjs.org/docs/react-component.html#componentdidupdate
|
# ? Sep 4, 2018 21:13 |
|
Baller, thanks. Ape Fist fucked around with this message at 21:54 on Sep 4, 2018 |
# ? Sep 4, 2018 21:26 |
|
Looking for wisdom on mixing CSS grid's requirement that (AFAIK) grid items must be the highest-level children of the container, and React requiring JSX snippets to be in their own container.JavaScript code:
Dominoes fucked around with this message at 11:03 on Sep 5, 2018 |
# ? Sep 5, 2018 10:58 |
|
Dominoes posted:Looking for wisdom on mixing CSS grid's requirement that (AFAIK) grid items must be the highest-level children of the container, and React requiring JSX snippets to be in their own container. You can either use React.Fragment, which was added in React 16, or use ”display: contents” in the css for the divs. I would reccomend using fragments https://reactjs.org/docs/fragments.html
|
# ? Sep 5, 2018 11:04 |
|
Thank you - fragment solved it elegantly. I'll be making liberal use of it from here on. Explicitly, the fix was replacing the final <div></div> pair with <></> Dominoes fucked around with this message at 22:58 on Sep 5, 2018 |
# ? Sep 5, 2018 21:59 |
|
My apps are littered with fragments. I really hope in the future that we won't need them at all anymore but they're a nice feature in the meantime.
|
# ? Sep 6, 2018 04:19 |
|
Someone told me once that doing @import React, { Component, Fragment } from 'react' is bad and just using React.Component and React.Fragment is better is this true? Does it matter? I guess it is redundant to import them directly? Vue's single file components with the CSS right there is really wooing me rn. I do the same thing a lot with styled-components in React more or less but drat it's nice to just write scoped CSS.
|
# ? Sep 6, 2018 20:36 |
|
my bony fealty posted:Vue's single file components with the CSS right there is really wooing me rn. You can do this with Angular as well?
|
# ? Sep 6, 2018 20:38 |
|
Ape Fist posted:You can do this with Angular as well? Yeah it's angular's default behavior.
|
# ? Sep 6, 2018 20:52 |
|
Anyone working with react/redux? I have a high level pattern question. So I have this component where the UI is broken out into steps, so only one sub component is shown at a time as the user progresses through. The actual content for the steps are broken out into their own components, my question is, whats the best way to let the parent component know that step 1 component finished what it needed to do, and it should move onto step 2. Right now step 1 takes in some data from the user, and stores it in my redux store. Once thats stored, I want to move onto step two. Should the parent component just be watching the store to wait for the info step 1 is responsible for to be there? Or should I pass in a callback prop to the nested step components to fire off when they are complete?
|
# ? Sep 6, 2018 21:39 |
|
ddiddles posted:The actual content for the steps are broken out into their own components, my question is, whats the best way to let the parent component know that step 1 component finished what it needed to do, and it should move onto step 2.
|
# ? Sep 6, 2018 22:21 |
|
Yeah, react allows you to create a function that modifies state on a component, then pass that function as a prop to the child. When the child runs that function, the parent state gets updated, not the child, allowing the parent to be aware of what the child is doing. Or just do it in redux and map state to props, problem solved
|
# ? Sep 6, 2018 22:51 |
|
my bony fealty posted:Someone told me once that doing @import React, { Component, Fragment } from 'react' is bad and just using React.Component and React.Fragment is better is this true? Does it matter? I guess it is redundant to import them directly? you can write import React, {Component} from 'react' right now because babel incorrectly interprets the finalized es module spec; it's not valid javascript. The correct thing to do, which will not break when you stop using babel to compile to modern javascript, is to import React and then use React.Component.
|
# ? Sep 7, 2018 02:29 |
|
Ape Fist posted:Can someone who has worked on Angular AND React give me reasons to like one or the other? Ape Fist posted:Btw I'm talking about Angular, not AngularJS Still using the term Angular. It's pedantic, but if you're fundamentally changing everything choose a loving different product name, Google.
|
# ? Sep 7, 2018 04:38 |
|
geeves posted:Still using the term Angular. Ugh no you're absolutely right. One of the main reasons Angular sits behind React is because of the gigantic naming mistake. Because people see 'Angular' and assume they're talking about AngularJS and go ughhh I'm not touching that poo poo. Ape Fist fucked around with this message at 09:07 on Sep 7, 2018 |
# ? Sep 7, 2018 09:01 |
|
Ape Fist posted:Ugh no you're absolutely right. It's also terrible for SEO, but what would Google know about that?
|
# ? Sep 7, 2018 14:00 |
|
The Merkinman posted:It's also terrible for SEO, but what would Google know about that? Perhaps Google is blind to AngularJS' reputation in the same way that Microsoft is blind to IE's reputation.
|
# ? Sep 7, 2018 14:10 |
|
The Merkinman posted:It's also terrible for SEO, but what would Google know about that? Google's spider has run JS for years now. Love Stole the Day posted:Perhaps Google is blind to AngularJS' reputation in the same way that Microsoft is blind to IE's reputation. They know. They've been trying to get people off of it since Edge came out because they don't want to support IE any more than they want to support XP
|
# ? Sep 7, 2018 14:30 |
|
Munkeymon posted:Google's spider has run JS for years now. I was referring to the latter, having a product vastly different/improved from its predecessor, but with the same name. *searches for Angular* --results come in referring to AngularJS-- *searches for Angular 2/6/etc*
|
# ? Sep 7, 2018 14:40 |
|
Ape Fist posted:Ugh no you're absolutely right. yeah. angularjs was hilariously terrible and it was amazing it got as popular as it ever did - between angular and google closure there was a point where I couldn't take google seriously, and would just refuse to work at any company stupid enough to use angularjs. angular was so different than angularjs that people mostly didn't port and just kept using angularjs, and would use react for new projects just because react was more mature at that time and since they'd have to learn a new framework anyway... angular doesn't use 'virtual dom', it uses direct rendering with change detection (e.g. dom is only updated when model is actually changed.) in terms of rendering speed, angular is generally going to be on par or slightly faster than react (https://www.stefankrause.net/wp/?p=454), although react has an advantage in memory use and initial display performance (although if you care about initial display, use server side rendering!)
|
# ? Sep 7, 2018 14:43 |
|
Munkeymon posted:They know. They've been trying to get people off of it since Edge came out because they don't want to support IE any more than they want to support XP
|
# ? Sep 7, 2018 14:55 |
|
For those who write React, how do you deal with cancelling requests that set state, but the component has unmounted before the request finishes? Currently trying to solve the problem of 1. Users gets to page 2. ComponentDidMount and Request fires 3. Users navigates away 4. Component unmounts 5. Request finishes and tries to set state 6. Console error Trying to find an elegant way of doing it. code:
|
# ? Sep 7, 2018 14:58 |
|
Grump posted:For those who write React, how do you deal with cancelling requests that set state, but the component has unmounted before the request finishes? My naive first impression is to check in the callback function that the state still is valid before it does anything. Or, again naive first impression here, you could check that the component still exists in the callback function. Though I don't see how a request would try to update the state of a component that may or may not exist. That sounds like a problem that can be fixed by improving/refactoring the design.
|
# ? Sep 7, 2018 15:21 |
|
https://reactjs.org/docs/react-component.html#componentwillunmount Nm that was right, handle the cancelling of the request in here.
|
# ? Sep 7, 2018 16:39 |
|
The Merkinman posted:I was referring to the latter, having a product vastly different/improved from its predecessor, but with the same name. Yeah, Angular and Go (but to a lesser extent) are both ironically Google-hostile, which is pretty funny. Love Stole the Day posted:I don't know, just because they rebrand doesn't mean they're not blind to it. They could just as easily be rationalizing it as a pure branding issue only rather than a performance or software issue, which would explain why it isn't that much better anyway. Rebrand? Edge is basically a ground-up rewrite and they even exist side-by-side on Windows 8+. Microsoft set up a site encouraging users to leave IE, though I can't remember the domain they picked, and had a site dedicated to providing developers resources to transition to modern browsers. They did all that because it was less manpower than making and maintaining an IE 12 that wasn't hot garbage would have been. Edge itself is fine - performs well enough and consistently gets modern features added in a timely fashion. The real boat anchor in terms of feature adoption the past few years is Safari.
|
# ? Sep 7, 2018 16:41 |
|
I'm just telling recruiters or anyone who asks that there's 'Angular' and 'AngularJS', 'Angular' refers to anything after Angular JS (i.e. Angular 2/4/5/6/7, etc.) and AngularJS refers to AngularJS, which is how Google wants you to name poo poo anyway.
|
# ? Sep 7, 2018 16:57 |
|
Edge is a rebrand of IE like a PC is a rebrand of the typewriter. (ok, I exaggerate a tiny bit)
|
# ? Sep 7, 2018 16:59 |
|
Imagine if Google went with Dart over TypeScript in Angular.
|
# ? Sep 7, 2018 17:04 |
|
|
# ? Jun 6, 2024 20:26 |
|
Ape Fist posted:I'm just telling recruiters or anyone who asks that there's 'Angular' and 'AngularJS', 'Angular' refers to anything after Angular JS (i.e. Angular 2/4/5/6/7, etc.) and AngularJS refers to AngularJS, which is how Google wants you to name poo poo anyway. Trying to educate recruiters on this stuff is a fool's errand. See: the number of calls I get about Java jobs, because I have JavaScript on my CV and hey they've gotta be at least close to the same thing, right? Google hosed up and should have called Angular something else entirely. AngularJS had its issues for sure, but I don't think it was a bad as some of you are remembering.
|
# ? Sep 7, 2018 17:21 |