|
Grump posted:Cool I'll check these out. I spent the day at working watching a lot of the Angular 2 Lynda vids and I've concluded that none of it makes sense and I hate it. React is much, much simpler than Angular namely because it tries to do a lot less. I don't fault anyone for choosing Angular but personally I can't stand it.
|
#
?
Jan 6, 2017 04:18
|
|
|
|
| # ? Jun 4, 2024 17:45 |
|
|
If you want an Angular that is simpler but not less powerful you can try Ember out. Good performance, shouldn't be as confusing to get in to as Angular, better development model, a great build tool (that create-react-app is probably modelled after), and a very good process for upgrading.
|
|
#
?
Jan 6, 2017 05:35
|
|
|
Lumpy posted:React is much, much simpler than Angular namely because it tries to do a lot less. I don't fault anyone for choosing Angular but personally I can't stand it. Angular is a lot like JavaScript itself, in that there's a lot of stuff you should ignore and never use, but can't be removed for backwards comparability purposes.
|
|
#
?
Jan 6, 2017 05:42
|
|
|
If you're coming at frameworks fresh, I heartily recommend checking out Aurelia too.
|
|
#
?
Jan 6, 2017 08:45
|
|
|
Plavski posted:If you're coming at frameworks fresh, I heartily recommend checking out Aurelia too. Yeah. Only been using jQuery. I'm just looking for something new to learn. I don't really know what I want to make
|
|
#
?
Jan 6, 2017 14:52
|
|
|
Skandranon posted:Angular is a lot like JavaScript itself, in that there's a lot of stuff you should ignore and never use, but can't be removed for backwards comparability purposes. Another reason to avoid it. Plus I always get a kick out you helping people who are starting out and saying "Oh god, don't read the docs! It's full of bad habits, read this blog post instead!" Not that React is perfect or for everyone, but Angular is just a giant minefield you have to learn to navigate on top of the whole "building your app" bit.
|
|
#
?
Jan 6, 2017 14:55
|
|
|
Lumpy posted:Another reason to avoid it. Plus I always get a kick out you helping people who are starting out and saying "Oh god, don't read the docs! It's full of bad habits, read this blog post instead!" Not that React is perfect or for everyone, but Angular is just a giant minefield you have to learn to navigate on top of the whole "building your app" bit. Looks like I forgot the "but it does have some really good parts, like JavaScript". However, unlike JavaScript, you do have options.
|
|
#
?
Jan 6, 2017 17:53
|
|
|
Any idea why I hit 10 digest iterations when returning a promise from a controller? I have a Plunker: https://plnkr.co/EpgFxCG31O3P4DXu3wcf It's pretty simple though. This will cause pants making GBS threads: code:
|
|
#
?
Jan 6, 2017 20:15
|
|
|
Rocko Bonaparte posted:Any idea why I hit 10 digest iterations when returning a promise from a controller? So the reason this happens is you are rendering the function result in the template, not the promise result. Every time Angular digests, it actually does it's digest check twice, to ensure the digest is stable. So you will see that function get called at least twice in the perfect case. However, since that function result is always going to be returning a NEW promise object each time, the digest will never be considered stable, and thus, you will always hit infinite digest. Consider a simpler example of why {{ Date.now() }} will have the same problem.
|
|
#
?
Jan 6, 2017 21:55
|
|
|
Grump posted:Cool I'll check these out. I spent the day at working watching a lot of the Angular 2 Lynda vids and I've concluded that none of it makes sense and I hate it. Ok cool so I spent the day watching some React videos. I didn't like the Egghead ones because they were a little too fast-paced for me, but I found some other neat Lynda videos that were more dumbed-down that helped me walk through it. I'm still having trouble getting the point of these frameworks. I don't get the lure in having javascript and html in one file instead of having everything separate. I get that it provides a better flow and that code is easily readable from top to bottom, but my brain doesn't work that way and I'm getting really confused. Is it wrong to just like doing things with HTML and Jquery or is this the way all web development is going? I'm gonna keep at it though. Very interesting. This stuff just makes me feel really dumb.
|
|
#
?
Jan 6, 2017 23:26
|
|
|
Grump posted:Ok cool so I spent the day watching some React videos. I didn't like the Egghead ones because they were a little too fast-paced for me, but I found some other neat Lynda videos that were more dumbed-down that helped me walk through it. The goal isn't really to put JS into HTML (Angular) or put HTML into JS (React), as both break down at large scale, so much as it is to abstract away DOM manipulation so you can focus on building your application instead of constantly attaching event handlers and creating/destroying DOM elements.
|
|
#
?
Jan 6, 2017 23:28
|
|
|
Grump posted:Ok cool so I spent the day watching some React videos. I didn't like the Egghead ones because they were a little too fast-paced for me, but I found some other neat Lynda videos that were more dumbed-down that helped me walk through it.
|
|
#
?
Jan 7, 2017 00:33
|
|
|
Skandranon posted:So the reason this happens is you are rendering the function result in the template, not the promise result. Every time Angular digests, it actually does it's digest check twice, to ensure the digest is stable. So you will see that function get called at least twice in the perfect case. However, since that function result is always going to be returning a NEW promise object each time, the digest will never be considered stable, and thus, you will always hit infinite digest. Okay I was afraid of something like that. I was running on some damaged notion that views could work with promises, but it looks like it works with them by banging on them multiple times. I am assuming I could alternate cache the value and return the promise just once. Is there a typical check for that? I have assumed that is the wrong way to go, and I wound up in what I regard as a deeper pit. In particular: code:Part of this is a larger dataflow issue I'm having. I ended up creating a controller that is instantiated once per row that maintains the state I was previously trying to query for each row. Each row's controller has a variable to store the eventual outcome of that logic. That keeps me from vomiting an endless stream of Promise objects and pissing off of the $digest loop. I'm now trying to figure out how to refresh them. The ng-repeat is iterating over some data provided by once controller. Each row is then checking that against a list in a different service. None of this automatically updates. At that point, I have each of those controllers listening for an event emitted from that service when the collection changes. I was hoping to avoid doing something like that. At this point, it's all moot because that data itself somehow turns into a Promise and when I get to the end of my chain of then statements, I still somehow have a Promise versus real data. Edit: Oh hooray, Resources aren't promises. I have to use $promise on them. gently caress that poo poo. Rocko Bonaparte fucked around with this message at 01:33 on Jan 7, 2017 |
|
#
?
Jan 7, 2017 00:48
|
|
|
Rocko Bonaparte posted:Okay I was afraid of something like that. I was running on some damaged notion that views could work with promises, but it looks like it works with them by banging on them multiple times. I am assuming I could alternate cache the value and return the promise just once. Is there a typical check for that? I have assumed that is the wrong way to go, and I wound up in what I regard as a deeper pit. Angular doesn't 'hammer' promises to deal with them, anything referenced in a template is executed during digest. That's what a digest is, to render the DOM. If you have a reference to a function, like you do, it gets called dynamically for every digest. Having a controller per row is no big deal, but I bet you are doing it in the wrong way. Consider the controller to simply be the interface between the template and the rest of your application. It shouldn't actually be holding any real state. The controller would reference other things to get state. Do you need to do separate HTTP calls to get each row? Why not a single service that stores your list, has a LoadAll (or LoadSome) method. This should populate some array in that service. You then have a controller which references that service, and it's template does an ng-repeat over service.list. For each row, you pass in the object to another component (<my-row ng-repeat="o in service.list" obj="o"> </my-row>. Now my-row gets it's object without any promise fuckery, and can render the fields within however it needs to. If something changes service.list[0].name, the UI will automatically update with this upon the next digest. Also, don't use ngResource, it makes doing simple HTTP work more complicated than it needs to be.
|
|
#
?
Jan 7, 2017 01:58
|
|
|
Anony Mouse posted:Also IMO Angular's nomenclature suuuucks but React's is very intuitive for me personally. See, I feel the exact opposite. React has a bunch of dumb new words that make no sense, but Angular makes (and has always made) perfect sense to me...
|
|
#
?
Jan 7, 2017 02:00
|
|
|
Thoughtworks says "Adopt" React, Redux, Ember. "Hold" on Angular 1 with no mention of 2. Also 4 is coming out soon! https://www.thoughtworks.com/radar Redux finally has some better documentation now and Abramov has provided or updated his opinions on some of the painful parts of React that I like to bitch about. Also, React-redux 5.0 is out and has some really nice improvements.
|
|
#
?
Jan 7, 2017 03:40
|
|
|
Rocko Bonaparte posted:Okay I was afraid of something like that. I was running on some damaged notion that views could work with promises, but it looks like it works with them by banging on them multiple times. I am assuming I could alternate cache the value and return the promise just once. Is there a typical check for that? I have assumed that is the wrong way to go, and I wound up in what I regard as a deeper pit. Dude. I can't imagine what you are trying to even do. Most applications eventually boil down to CRUD and Angular and React both excel at that. Forget code, don't type an example, don't talk about promises. What are you trying to accomplish?
|
|
#
?
Jan 7, 2017 04:58
|
|
|
HaB posted:Dude. I can't imagine what you are trying to even do. Most applications eventually boil down to CRUD and Angular and React both excel at that. I am setting up a searchable catalog for internal software packages we need to use for things. They are for all kinds of OSes in all kinds of different package formats. People working on a new project need to be able to figure out what goes with what, how it is used, who used it for what recently, what kind of things they got out of it, and things like that. A lot of that data is being submitted directly through a REST API; the client-side stuff searches and creates the collections. It's expected power users will select items out of the catalog, click a button, and submit a job to a back end that will turn the collection into a metapackage and get it set up on a disk image. So users need to be able view the catalog records generally, and then do CRUD with collections of them. Everything went to poo poo for me when I had to mix the catalog with a designated collection to be able to add or remove packages from the collection right from the catalog view. At the beginning of the holidays, I was stuck with an issue of telling the back end to add or remove packages by their ID. In particular, my Django REST API expected a PATCH request to modify which packages are in a given collection. I eventually was able to instruct ngResource to do a PATCH request on updates, and I can't recall why exactly it just didn't work for me. I came back from the holidays with the PATCH operation working, but the request being wrong, so I just about panicked that I was still stuck, but that was fixed. This week then was: 1. Getting a view of all the collections. 2. Being able to create and delete collections. 3. Selecting a collection to be active. 4. Add and removing packages from that collection. The last one there was there things got really wild. I started with my original catalog listing view and started adding logic to put add or remove controls beside each catalog entry of a collection was active. I can't even go through the progression of gently caress-ups but it boiled down to: 1. Misinterpreting the result of my query for the collection as a promise when it was a Resource. I just looked at it sloppily in the debugger, saw promise, and then went on my way. Then I wondered how I was getting promises in my .then() statements. I figured out I needed to be waiting on my resource.$promise, not the resource itself. 2. A funny one where inside my .then I was setting this.collection, without realizing I was setting that for the promise, not my service.  Once I figured out I was returning the resource and not the promise, I was able to resolve the active collection in my active collection service, and get rid of most of the $q.when() statements I was spraying everywhere. It naturally didn't work because I was creating a promise out of the resource, rather than chaining code to work on the result of the resource's promise. Anyways, Skandranon is actually wrong about me doing a query on every row but right about the approach being faulty. I was hoping to get to a point of stability before taking a breath and thinking about what just happened. My conclusion is that when I smashed the collection into the catalog list, I needed to make a controller to reconcile that logic and shove all the redundant code from the separate controller into services and factories. I had pondered something like going over an array of the fields myself because I don't think I like have a henhouse full of little controllers, each independently pecking on its own row in the table. I had to do signals to get them to refresh when I changed the collection. I would have likely recognized this earlier if I had done this before, but I had incrementally created my catalog view, then my collection view, and got lost trying to merge them together. I will likely put an hour or two into TypeScript to see what the deal is because I've definitely been loving up my data typing; the resource not be a promise is at the top of my list of fuckups. Also, the IRC channel for angular was hilarious about this. I basically asked, "if I do $q.when(some_promise).then(function(some_var) {...}); shouldn't I be able to assume some_var is resolved?" The answer: I should use underscores in my globals (link to some eslint policy to catch that). 
|
|
#
?
Jan 7, 2017 07:02
|
|
|
Rocko Bonaparte posted:stuff Ok, here's what I think you should do. 1. Spend a bit of time learning TypeScript. Specifically, focus on interfaces. 2. Think about you applications data structure. If it is coming in from different sources, it would make more sense to have some code clean it up in your application once you receive it instead of trying to deal with it piecemeal all over the place. Create Interfaces for everything so you get type safety and intellisense. 3. Stop using ngResource, it's garbage. 4. Start writing a data layer service. This should be the only thing that uses $http. Write very simple methods, of the form code:6. Consume your promises in your controllers/services, and assign result to controller fields to then be mapped to template, do not dump promises onto $scope and reference them.
|
|
#
?
Jan 7, 2017 07:59
|
|
|
Skandranon posted:Ok, here's what I think you should do. Yeah. Basically all of this, tho I remain ambivalent with regards to TypeScript. If you say you need it, go for it. To further clarify: don't let your data sources dictate how your application behaves. That's why you need a data layer. Collect data from wherever you need to, then transform it into what your application needs. But your app's design/behavior should be driven by the business rules, not the data structure coming from your various sources. So instead of "making the app work with the data I am getting" your approach should be more of "transform the data to work with my app." Let services and directives do the bulk of the work and let your controllers be as dumb as possible. When I have a controller that starts getting above 250 lines, I start looking for places to move some of that work elsewhere. That's a line count I use as a guideline, you should come up with your own based on your own style.
|
|
#
?
Jan 7, 2017 14:25
|
|
|
HaB posted:Yeah. Basically all of this, tho I remain ambivalent with regards to TypeScript. If you say you need it, go for it. I've found it to be incredibly useful, coming from a C# background, and I would think the Intellisense it provides is unconditionally good. There is a cost to getting it going, but I've found that to be very small in comparison to the benefits. But I'll admit you can write perfectly good Angular apps without it.
|
|
#
?
Jan 7, 2017 20:07
|
|
|
All the courses on Udemy are  each for a few more days. Has anyone taken any of them, and are they worth it? If so, do you have recommendations? I'm most interested in React, Angular, and Vue courses, but I'm open to anything JS or Python if it's a really fantastic course.
|
|
#
?
Jan 7, 2017 21:12
|
|
|
camoseven posted:All the courses on Udemy are I cant recommend Anthony Alicea's courses enough. He has a full course on Angular, though I havent taken it yet. I've done his Javascript course and am currently doing his node.js course, and they are great. https://www.udemy.com/user/anthonypalicea/
|
|
#
?
Jan 7, 2017 22:58
|
|
|
Professor of Cats posted:Man that sounds super familiar... Finally got a chance to address this, and implementing your advice seems to have completely fixed the problems. Thank you so much!
|
|
#
?
Jan 10, 2017 06:32
|
|
|
Just made it to alpha  with my first big Redux project, for which I was completely on the hook after two years of evangelizing. Things have turned out pretty great so far but I had to push the schedule a few times. This was mainly due to underestimating the learning curve of doing Redux right(er). I was fairly proficient in React, but had only done enough toy projects and Abramov-viewing to feel 'confident but green' with Redux.biggest lessons learned:
VV Helicity posted:Have you tried VS Code? It's amazing and slowly wins over almost every atom/webstorm/sublime dev, from my experience. Pulled it down when it first came out for novelty factor, but I've never given it a serious look. I'll check it out! Kekekela fucked around with this message at 14:18 on Jan 10, 2017 |
|
#
?
Jan 10, 2017 13:17
|
|
|
Kekekela posted:Biggest Lessons learned: A lot of the questions in this thread would be better served by giving heed to these two items. Anyone coming from more opinionated frameworks like Rails or .NET MVC might be used to assuming a solid foundation where they can do bottom-up design and easily extend proof of concepts. React requires you to establish that foundation, has several non-intuitive ways of doing it, and when you combine those with a dynamically typed, expressive language like Javascript, you can easily shoot yourself in the foot. Kekekela posted:[*]MS Only: Use Sublime and Powershell (or webstorm, atom, etc), the VS support for React, npm, and webpack is encouraging but not there yet Have you tried VS Code? It's amazing and slowly wins over almost every atom/webstorm/sublime dev, from my experience.
|
|
#
?
Jan 10, 2017 13:56
|
|
|
We're a big in-house VS2013-15 crew for our C# and static TypeScript needs for our main product, but I'm going hardcore into VSCode for our framework-driven next product. It's such a nice environment; every update makes it easier to sell to my colleagues too.
|
|
#
?
Jan 10, 2017 14:18
|
|
|
https://twitter.com/smallbellamy/status/740034053609562112
|
|
#
?
Jan 10, 2017 23:46
|
|
|
I'm amazed at how few replies you have made.
|
|
#
?
Jan 11, 2017 14:24
|
|
|
ddiddles posted:I cant recommend Anthony Alicea's courses enough. He has a full course on Angular, though I havent taken it yet. I've done his Javascript course and am currently doing his node.js course, and they are great. I got his node.js course cause of your recommendation in another thread, but then I was busy last night and forgot to get anything else before the sale ended 
|
|
#
?
Jan 11, 2017 18:06
|
|
|
camoseven posted:I got his node.js course cause of your recommendation in another thread, but then I was busy last night and forgot to get anything else before the sale ended Udemy frequently has sales. There have been like three or four $10 sales since Black Friday. Check back in like a week or two and they'll probably have another one.
|
|
#
?
Jan 11, 2017 21:38
|
|
|
camoseven posted:I got his node.js course cause of your recommendation in another thread, but then I was busy last night and forgot to get anything else before the sale ended 90% of the course is great, really goes into how node leverages it's C++ base and modified V8 engine to allow you to do some cool poo poo just using JS. Then I got to the part at the end where you are supposed to code a simple todo app using mongo and node, and all of a sudden he went "Oh yeah, it might be fun to use Angular 2, and it's all in typescript so just copy and paste what I write, this isn't a course on angular". It came out of left field because everything new concept in the course is preceded by a few videos that go into whats going on in the background except for this, and kind turned me off on the rest of the course (which has yet to be released, but he's good about pushing out content fast). Again, the majority is awesome and well worth
|
|
#
?
Jan 11, 2017 22:54
|
|
|
ddiddles posted:90% of the course is great, really goes into how node leverages it's C++ base and modified V8 engine to allow you to do some cool poo poo just using JS. That sounds incredibly cool - I've always wondered how that part works.
|
|
#
?
Jan 12, 2017 00:50
|
|
|
Helicity posted:Have you tried VS Code? It's amazing and slowly wins over almost every atom/webstorm/sublime dev, from my experience. Agreed, vscode is amazing.
|
|
#
?
Jan 12, 2017 08:39
|
|
|
There's a minor war going on in my department. The cool, smart and driven JavaScript developer - me - is trying to instruct the old, C# wielding dinosaurs that Visual Studio isn't the panacea they think it is. Writing TypeScript in VS is pretty grim when you try and do anything out of the ordinary. VSCode just eats that stuff up. The team actively tries to build their code around the limitations rather than embrace the new. Oh for a job where I was swimming with the current instead of against it!
|
|
#
?
Jan 12, 2017 11:41
|
|
|
Tivac posted:Agreed, vscode is amazing. Man I'm kind of champing at the bit to try it now but I'm like 2 weeks out from having some breathing room 
|
|
#
?
Jan 12, 2017 14:12
|
|
|
Plavski posted:There's a minor war going on in my department. The cool, smart and driven JavaScript developer - me - is trying to instruct the old, C# wielding dinosaurs that Visual Studio isn't the panacea they think it is. Writing TypeScript in VS is pretty grim when you try and do anything out of the ordinary. VSCode just eats that stuff up. The team actively tries to build their code around the limitations rather than embrace the new. Oh for a job where I was swimming with the current instead of against it! source your grog quotes
|
|
#
?
Jan 12, 2017 14:14
|
|
|
Gul Banana posted:source your grog quotes Life is tough in the coding trenches, my friend. It must be how my grandfather felt in WW2.
|
|
#
?
Jan 12, 2017 14:24
|
|
|
Tivac posted:Agreed, vscode is amazing. It's no VIM, but it's not bad for a non-VIM thing. 
|
|
#
?
Jan 12, 2017 17:34
|
|
|
|
| # ? Jun 4, 2024 17:45 |
|
|
Plavski posted:There's a minor war going on in my department. The cool, smart and driven JavaScript developer - me - is trying to instruct the old, C# wielding dinosaurs that Visual Studio isn't the panacea they think it is. Writing TypeScript in VS is pretty grim when you try and do anything out of the ordinary. VSCode just eats that stuff up. The team actively tries to build their code around the limitations rather than embrace the new. Oh for a job where I was swimming with the current instead of against it! This is exactly how my current job started, with an Angular/TypeScript project built around VS. It was awful. Fortunately, there was no one to stand in my way of throwing all that out and moving it and all other UI projects to VSCode. Things have been much better since then. Keep fighting, the paradise you seek is real.
|
|
#
?
Jan 12, 2017 17:41
|
|