Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Anyone using redux?

I'm a few days into a new React project and I decided to dive into using redux instead of conventional flux, and man...so far, it really meshes with the way I think in much the same React did when I first started using it.

Like React (and unlike Flux, and most of the Flux libraries, in my experience), it's conceptually simple, has a small API, and yet makes reasoning about and building apps more robust.

The basic idea is that your whole application state is stored in one place, and actions are just pure functions that modify that state and return a new state. The documentation is pretty good at explaining it, so if it sounds interesting to you check it out.

# ? Oct 12, 2015 22:52

Adbot: ADBOT LOVES YOU

# ? May 18, 2024 12:26

WORLDS BEST BABY: Aug 26, 2006

Thermopyle posted:

Anyone using redux?

I'm a few days into a new React project and I decided to dive into using redux instead of conventional flux, and man...so far, it really meshes with the way I think in much the same React did when I first started using it.

Like React (and unlike Flux, and most of the Flux libraries, in my experience), it's conceptually simple, has a small API, and yet makes reasoning about and building apps more robust.

The basic idea is that your whole application state is stored in one place, and actions are just pure functions that modify that state and return a new state. The documentation is pretty good at explaining it, so if it sounds interesting to you check it out.

I started using it for a project this week, and was already very impressed with it before I found out about the incredible devtools ,which allow time-travelling, hot-reloading debugging of your stores. This talk by Redux's creator on the topic is well worth checking out if you want to see what I mean:

https://www.youtube.com/watch?v=xsSnOQynTHs

Also being able to apply middleware to your store creators to instantly add undo/redo to your app�s state just seems too good to be true. But it's real!

# ? Oct 12, 2015 23:06

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

double post

# ? Oct 12, 2015 23:08

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Thermopyle posted:

Anyone using redux?

I'm a few days into a new React project and I decided to dive into using redux instead of conventional flux, and man...so far, it really meshes with the way I think in much the same React did when I first started using it.

Like React (and unlike Flux, and most of the Flux libraries, in my experience), it's conceptually simple, has a small API, and yet makes reasoning about and building apps more robust.

The basic idea is that your whole application state is stored in one place, and actions are just pure functions that modify that state and return a new state. The documentation is pretty good at explaining it, so if it sounds interesting to you check it out.

I have been reading a ton on it and yeah, it "clicks". I am about 85-90% done with a project on which I used alt, but I think I might say screw it and switch over.

# ? Oct 12, 2015 23:54

ddiddles: Oct 21, 2008; Roses are red, violets are blue, I'm a schizophrenic and so am I

How much vanilla javascript knowledge is required for an entry level front end dev job?

I've been doing HTML/CSS work for the past five or so years, but it was usually because I was the companies IT guy, so obviously I must know "how to make the internet sites". I'm pretty comfortable with HTML5/CSS3 and can build a responsive site from scratch, but my javascript experience was really lacking, mostly consisting of taking premade scripts/plugins and knowing enough to implement and edit the basics of them to fit the company needs.

I'm moving from the US to the UK in 8 months, and really wanted to get my skills up to be able to land an entry level front end job, so I've been focusing on learning vanilla javascript before moving on to any frameworks.

I know it's kind of an open ended question, but does anyone know of some sort of checklist of concepts/abilities most entry level dev jobs require?

EDIT: Realized theres a newbie get a job thread, I'll move it if this question doesn't belong here.

ddiddles fucked around with this message at 07:13 on Oct 15, 2015

# ? Oct 15, 2015 07:09

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

ddiddles posted:

How much vanilla javascript knowledge is required for an entry level front end dev job?

I've been doing HTML/CSS work for the past five or so years, but it was usually because I was the companies IT guy, so obviously I must know "how to make the internet sites". I'm pretty comfortable with HTML5/CSS3 and can build a responsive site from scratch, but my javascript experience was really lacking, mostly consisting of taking premade scripts/plugins and knowing enough to implement and edit the basics of them to fit the company needs.

I'm moving from the US to the UK in 8 months, and really wanted to get my skills up to be able to land an entry level front end job, so I've been focusing on learning vanilla javascript before moving on to any frameworks.

I know it's kind of an open ended question, but does anyone know of some sort of checklist of concepts/abilities most entry level dev jobs require?

EDIT: Realized theres a newbie get a job thread, I'll move it if this question doesn't belong here.

You're going to confuse people if you say you're comfortable with HTML5 but aren't a javascript developer. The interesting parts of HTML5 are the apis exposed to javascript developers (like HTML5 canvas/web storage/<video tag>/HTML5 drag and drop/ File API/ geolocation).

# ? Oct 15, 2015 12:30

luchadornado: Oct 7, 2004; A boombox is not a toy!

For those React people, is there a cleaner way of accomplishing the following? If calling an event handler with a parameter, you need to wrap it in an anonymous function and it looks horrid in more complex examples:

code:

var self = this;
var index = 1;
return (<input type="text" onChange={function() { self.handleBlockNameChange(index); }} />)

opposed to a parameterless call:

code:

return (<input type="text" onChange={self.handleBlockNameChange} />)

# ? Oct 28, 2015 16:54

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Helicity posted:

For those React people, is there a cleaner way of accomplishing the following? If calling an event handler with a parameter, you need to wrap it in an anonymous function and it looks horrid in more complex examples:
code:
var self = this;
var index = 1;
return (<input type="text" onChange={function() { self.handleBlockNameChange(index); }} />)
opposed to a parameterless call:
code:
return (<input type="text" onChange={self.handleBlockNameChange} />)

Well, if you are using babel, use arrow functions if you need to call with a parameter:

JavaScript code:

return (<input type="text" onChange={() => { this.handleBlockNameChange(1) }} />)

Or you can add data to the element and not need to pass a prop at all:

JavaScript code:

handleBlockNameChange(event) {
   const node = event.target;
   // get the data param from the node and do stuff...
   node.getAttribute('data-blah')
}

render() {
  return (<input type="text" data-blah="1" onChange={this.handleBlockNameChange} />)
}

Lumpy fucked around with this message at 17:05 on Oct 28, 2015

# ? Oct 28, 2015 17:03

M31: Jun 12, 2012

Depending on the signature, you can also use

code:

return (<input type="text" onChange={this.handleBlockNameChange.bind(this, index)} />)

# ? Oct 28, 2015 17:15

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Helicity posted:

For those React people, is there a cleaner way of accomplishing the following? If calling an event handler with a parameter, you need to wrap it in an anonymous function and it looks horrid in more complex examples:
code:
var self = this;
var index = 1;
return (<input type="text" onChange={function() { self.handleBlockNameChange(index); }} />)
opposed to a parameterless call:
code:
return (<input type="text" onChange={self.handleBlockNameChange} />)

A year or so ago I resigned myself to always using an ES6 (or ES2015 as they call it now) transpiler like babel because ES6 is just too useful to live without. If you come to accept having a build step integrated into your workflow, you can also throw other nice stuff in there like babel-plugin-react-transform.

So, as Lumpy mentioned, arrow functions are my favorite way to handle this.

# ? Oct 28, 2015 17:26

zorch: Nov 28, 2006

Can anyone make a case for/against Angular's controllerAs syntax? It seems like it breaks some of the "magic" Angular stuff you typically take for granted and I've yet to run into a problem with scope pollution while using the traditional approach.

# ? Oct 28, 2015 17:37

luchadornado: Oct 7, 2004; A boombox is not a toy!

Lumpy posted:

stuff

I was leaning toward doing the data attribs but that can get cumbersome. I didn't even think of the arrow... thanks!

# ? Oct 28, 2015 17:41

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

zorch posted:

Can anyone make a case for/against Angular's controllerAs syntax? It seems like it breaks some of the "magic" Angular stuff you typically take for granted and I've yet to run into a problem with scope pollution while using the traditional approach.

ControllerAs is a godsend, I always use it. $scope is largely a mistake in Angular, and something they are getting rid of in Angular 2.0. Sure, it seems like magic and lets you do things like a ToDo list with no lines of code (in a .js file, it's still in the html), but it becomes a real headache when trying to do larger applications. ControllerAs combined with BindToController upgrade your controllers to objects that can have methods and fields, instead of something that defines a bunch of methods and fields on the $scope. $scope then disappears and you can focus on your controller components. Combine this with TypeScript, and you have a bunch of strongly typed, well defined components with very little funny business going on in the background to trip you up.

# ? Oct 28, 2015 18:01

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Skandranon posted:

ControllerAs is a godsend, I always use it. $scope is largely a mistake in Angular, and something they are getting rid of in Angular 2.0. Sure, it seems like magic and lets you do things like a ToDo list with no lines of code (in a .js file, it's still in the html), but it becomes a real headache when trying to do larger applications. ControllerAs combined with BindToController upgrade your controllers to objects that can have methods and fields, instead of something that defines a bunch of methods and fields on the $scope. $scope then disappears and you can focus on your controller components. Combine this with TypeScript, and you have a bunch of strongly typed, well defined components with very little funny business going on in the background to trip you up.

Yeah, I've been using controllerAs from the outset of my first major Angular project and to this day I still don't know what the big deal is with getting rid of $scope. All of my methods and data retrieval are compartmentalized into each controller so it's a piece of cake to keep things out of $scope. The only thing I store on $scope (well, $rootScope) is a user's profile object, but that's mainly for convenience because it's accessed constantly throughout the app. Even then I could use router-ui's resolve {} property and remove $scope as a dependency in my modules.

# ? Oct 29, 2015 18:58

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Karthe posted:

Yeah, I've been using controllerAs from the outset of my first major Angular project and to this day I still don't know what the big deal is with getting rid of $scope. All of my methods and data retrieval are compartmentalized into each controller so it's a piece of cake to keep things out of $scope. The only thing I store on $scope (well, $rootScope) is a user's profile object, but that's mainly for convenience because it's accessed constantly throughout the app. Even then I could use router-ui's resolve {} property and remove $scope as a dependency in my modules.

You should probably move the user profile to a service so it can be more specifically accessed and managed. The only reason I still put $scope into all my controllers is because I always add a "this.$scope.$on("$destroy", this.dispose);" in the constructor, prompting the correct place to dispose of timers and watches, even if dispose is an empty method.

The big deal with getting rid of $scope is it takes away the thing that allows people to make terrible Angular apps, even though there are good ways to fix it in 1.3+. A lot of examples out there still talk about stuffing everything onto $scope.

That and people are babies and don't want things to ever change.

# ? Oct 29, 2015 19:14

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Skandranon posted:

You should probably move the user profile to a service so it can be more specifically accessed and managed.

Thank you for reminding me that I needed to go back and make my profile service suck less. I just refactored a lot of code to reference the profile service instead of a scope variable. This had the added benefit of forcing me to make a couple of my modules more generic so that I can reuse them in later projects :woop:

That said, I ended up writing the following bit of code and I was hoping to get some feedback on whether it's a good idea or not:

code:

vm.profile = ProfileService.getProfile();

$scope.$watch(function() {
		return ProfileService.getProfile();
	}, function(newVal) {
		console.log('profile changed');
		vm.profile = ProfileService.getProfile();
}, true);

I wrote this in a controller attached to a template that shows additional information if the user is logged in (the profile only gets loaded after an auth check). I wanted to keep things simple but I had to implement a $watch because, for some reason, vm.profile wasn't updating (as reflected by elements in the controller's template hiding or appearing). This is despite the fact that A) getProfile() returns null when the user logs out, and B) getProfile() returns an object when the user is logged in. Is there something I'm missing here?

# ? Oct 29, 2015 23:15

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Karthe posted:

Thank you for reminding me that I needed to go back and make my profile service suck less. I just refactored a lot of code to reference the profile service instead of a scope variable. This had the added benefit of forcing me to make a couple of my modules more generic so that I can reuse them in later projects

That said, I ended up writing the following bit of code and I was hoping to get some feedback on whether it's a good idea or not:
code:
vm.profile = ProfileService.getProfile();

$scope.$watch(function() {
		return ProfileService.getProfile();
	}, function(newVal) {
		console.log('profile changed');
		vm.profile = ProfileService.getProfile();
}, true);
I wrote this in a controller attached to a template that shows additional information if the user is logged in (the profile only gets loaded after an auth check). I wanted to keep things simple but I had to implement a $watch because, for some reason, vm.profile wasn't updating (as reflected by elements in the controller's template hiding or appearing). This is despite the fact that A) getProfile() returns null when the user logs out, and B) getProfile() returns an object when the user is logged in. Is there something I'm missing here?

This is probably a bad idea, as binding a watch to a function like that means that ProfileService.getProfile() gets called on EVERY digest, which is probably not needed. If it's just returning a value it already has, no biggie, but if it has to do any lookup, you're probably looking up too much. Actually, since it's not bound to an actual variable, it could be calling the function twice, once to get oldValue, then again to get newValue. Probably worth putting some logging in to see. You could bind your watch directly to ProfileService.profile to get the same result, less ambiguity.

# ? Oct 29, 2015 23:39

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Skandranon posted:

This is probably a bad idea, as binding a watch to a function like that means that ProfileService.getProfile() gets called on EVERY digest, which is probably not needed. If it's just returning a value it already has, no biggie, but if it has to do any lookup, you're probably looking up too much. Actually, since it's not bound to an actual variable, it could be calling the function twice, once to get oldValue, then again to get newValue. Probably worth putting some logging in to see. You could bind your watch directly to ProfileService.profile to get the same result, less ambiguity.

I originally made profile a public property of ProfileService but decided to hide it away behind a getProfile() method to make things a bit more encapsulated? In any case, getProfile() simply returns the now-internal profile object so there's no actual heavy lifting that goes on in that function.

And I added some logging. It seems the $watch calls getProfile() on average 14 times every time I navigate to another route :holy:

. That seems like a lot but if what you said is true then since that function is just returning an object then it seems it's alright to keep the $watch in place.

# ? Oct 30, 2015 00:00

HaB: Jan 5, 2001; What are the odds?

I like ControllerAs for reasons already pointed out, plus it means that if I see $scope somewhere, I know it's because I am doing one of the few things which requires it - $watch, $on, etc.

When I was first learning Angular, I'd say MOST of the online examples I found were bad - for reasons other than $scope - since I didn't know enough about $scope at the time to know using it like they were doing was bad. Instead they were bad because they were always so small and tightly focused that they'd gloss over things that seemed important to me. I'd love to see an Angular tutorial geared towards more experienced developers with discussion on how to layout the project, and even some Rosetta Stone style "if you came from X language, here is the Angular equivalent" stuff. Like ASP MVC -> Angular MVC, etc.

# ? Oct 30, 2015 12:56

prom candy: Dec 16, 2005; Only I may dance

What's everyone using for forms in a React/Redux environment? React-form-for seems interesting but I don't know if I'm biased towards Rails-y things.

# ? Oct 30, 2015 14:32

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

prom candy posted:

What's everyone using for forms in a React/Redux environment? React-form-for seems interesting but I don't know if I'm biased towards Rails-y things.

I just create them. I haven't really understood the point of using a library for forms, but that's probably more because I'm dumb rather than there not being an actual point.

# ? Oct 30, 2015 17:52

Stoph: Mar 19, 2006; Give a hug - save a life.

Thermopyle posted:

I just create them. I haven't really understood the point of using a library for forms, but that's probably more because I'm dumb rather than there not being an actual point.

I do the same by maintaining a basic data structure like this consistently on all my forms.

code:

{
    inputs: {
        key: val
    },
    errors: {
        key: [val]
    }
}

Any action in my store can update this map to reflect the current state of the form and the UI will re-render. I wire it all together manually without libraries but I'd love to figure out "the right way".

# ? Oct 31, 2015 05:42

luchadornado: Oct 7, 2004; A boombox is not a toy!

^^^ edit: I did something similar to that for hundreds of chunks of financial data. It's like of like a light-weight Flux pattern if you're using it the same way I did. For me the 'is this the right way' test is a) can my peers understand it b) if I come across the problem again do I hop right to that pattern.

Thermopyle posted:

I just create them. I haven't really understood the point of using a library for forms, but that's probably more because I'm dumb rather than there not being an actual point.

Same here, although I don't think it's dumb. At some point the dependency of a library just for something minor like forms seems like it will bite you in the rear end, so you should be doing some sort of ROI analysis - will X library save me time and make this code more maintainable?

I just have every input like:

code:

<input data-id="myPropertyName" onChange={this.handleFormChange} value={this.props.myPropertyName} />

and then have a handler:

code:

handleFormChange: function(e) {
  this.state[e.target.attributes['data-id']] = e.target.value;
  this.setState(this.state);
}

Depending on how simple your model is, you could make it even more easy by doing a map on properties of your state and automatically creating the input elements.

luchadornado fucked around with this message at 15:39 on Oct 31, 2015

# ? Oct 31, 2015 15:02

M31: Jun 12, 2012

If you are using Redux, not using redux-form makes it pretty tedious to create lots of forms that actually use Redux state.

Even if you are not using Redux, having a small form helper skips a lot of boilerplate every time: https://jsfiddle.net/r2o13s5h/
This is something I just whipped up and sucks, but hopefully it shows why the concept is useful.

# ? Oct 31, 2015 16:20

Ethereal: Mar 8, 2003

Helicity posted:

For those React people, is there a cleaner way of accomplishing the following? If calling an event handler with a parameter, you need to wrap it in an anonymous function and it looks horrid in more complex examples:
code:
var self = this;
var index = 1;
return (<input type="text" onChange={function() { self.handleBlockNameChange(index); }} />)
opposed to a parameterless call:
code:
return (<input type="text" onChange={self.handleBlockNameChange} />)

Two ways, use partial application through the Function.bind syntax or you can pass the parameter and function as props and have a handler that calls your passed in handler with the index.

# ? Oct 31, 2015 22:48

Gul Banana: Nov 28, 2003

Lumpy posted:

Or you can add data to the element and not need to pass a prop at all:

JavaScript code:

handleBlockNameChange(event) {
   const node = event.target;
   // get the data param from the node and do stuff...
   node.getAttribute('data-blah')
}

render() {
  return (<input type="text" data-blah="1" onChange={this.handleBlockNameChange} />)
}

the thing which worries me about this version is that if you tried to use this.props (or this.anything) in handleBlockNameChange it would fail. the example is fine but it seems error-prone.

# ? Nov 1, 2015 00:26

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Gul Banana posted:

the thing which worries me about this version is that if you tried to use this.props (or this.anything) in handleBlockNameChange it would fail. the example is fine but it seems error-prone.

You do this in your constructor and this.whatever works fine:

JavaScript code:

this.handleBlockNameChange = this.handleBlockNameChange.bind(this)

Or you could do this instead:

JavaScript code:

handleBlockNameChange  = (event) => {
   const node = event.target;
   // get the data param from the node and do stuff...
   node.getAttribute('data-blah')
   console.log(this.props) // hooray, it works!
}

Lumpy fucked around with this message at 02:19 on Nov 1, 2015

# ? Nov 1, 2015 02:16

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

If you're using the React.createClass notation, it works just fine without binding: https://jsfiddle.net/ah3q4LLd/

If you're using the ES2015 class notation, you can do it a few different ways:
binding `this`: https://jsfiddle.net/xuu88rgL/
anonymous functions: https://jsfiddle.net/ha0adqfj/

Or what Lumpy said.

# ? Nov 1, 2015 22:24

geeves: Sep 16, 2004

Skandranon posted:

ControllerAs is a godsend, I always use it. $scope is largely a mistake in Angular, and something they are getting rid of in Angular 2.0. Sure, it seems like magic and lets you do things like a ToDo list with no lines of code (in a .js file, it's still in the html), but it becomes a real headache when trying to do larger applications. ControllerAs combined with BindToController upgrade your controllers to objects that can have methods and fields, instead of something that defines a bunch of methods and fields on the $scope. $scope then disappears and you can focus on your controller components. Combine this with TypeScript, and you have a bunch of strongly typed, well defined components with very little funny business going on in the background to trip you up.

Karthe posted:

Yeah, I've been using controllerAs from the outset of my first major Angular project and to this day I still don't know what the big deal is with getting rid of $scope. All of my methods and data retrieval are compartmentalized into each controller so it's a piece of cake to keep things out of $scope. The only thing I store on $scope (well, $rootScope) is a user's profile object, but that's mainly for convenience because it's accessed constantly throughout the app. Even then I could use router-ui's resolve {} property and remove $scope as a dependency in my modules.

Thank you both for this. It gives me something new and hopefully better to implement. Currently I've been building factories similar to Java Objects (since my main background is Java) instead of $scope as it's much much easier to move data between two controllers via the factory than to deal with broadcast, emit and whatever else people have said to use (they never work). I have no idea why they are called Factories since as far as I can tell, they don't use the factory design pattern and are more useful as JS version of a Bean / Data Object.

Since the summer, I've been left picking up the pieces of a very, very bad angular implementation (the guy wrapped all of our JS into angular, then quit and basically said, "Yeah I did it completely wrong," on his way out the door) and trying to rectify everything since it really puts us in a corner with it. Seriously the way it was done probably cost our company a fuckton of money given how much we have to fix now. The same guy also put all of these functions on rootScope and really many of them are better in a Factory that acts more like a Util class.

As for TypeScript, I really like it so far. Granted I am just using it personally and implementing it locally, but I hope to get it into wider use in my company.

# ? Nov 2, 2015 02:48

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

geeves posted:

Thank you both for this. It gives me something new and hopefully better to implement. Currently I've been building factories similar to Java Objects (since my main background is Java) instead of $scope as it's much much easier to move data between two controllers via the factory than to deal with broadcast, emit and whatever else people have said to use (they never work). I have no idea why they are called Factories since as far as I can tell, they don't use the factory design pattern and are more useful as JS version of a Bean / Data Object.

Since the summer, I've been left picking up the pieces of a very, very bad angular implementation (the guy wrapped all of our JS into angular, then quit and basically said, "Yeah I did it completely wrong," on his way out the door) and trying to rectify everything since it really puts us in a corner with it. Seriously the way it was done probably cost our company a fuckton of money given how much we have to fix now. The same guy also put all of these functions on rootScope and really many of them are better in a Factory that acts more like a Util class.

As for TypeScript, I really like it so far. Granted I am just using it personally and implementing it locally, but I hope to get it into wider use in my company.

I really sympathize, I've been in much the same boat, with multiple major projects, but with blanket authority to change whatever I want. I would strongly push for using TypeScript in your Angular apps, there is literally no downside, and a LOT of improvements. I find reading plain old JavaScript painful now, TypeScript really is so much better, and it works really well with Angular.

For moving stuff between controllers, I'd look at something like AmplifyJS or PostalJS, and then use TypeScript to wrap around them to create a strongly typed message bus. Another good way to communicate is via Services and Promises. This method works well for things like modal dialog boxes, where there is a well defined request, and a well defined response. Whereas a message bus should be used for things which don't exactly have a well defined request or response, like events coming in from Websockets, or updating a part of the screen based on a timer.

# ? Nov 2, 2015 03:01

geeves: Sep 16, 2004

Skandranon posted:

I really sympathize, I've been in much the same boat, with multiple major projects, but with blanket authority to change whatever I want. I would strongly push for using TypeScript in your Angular apps, there is literally no downside, and a LOT of improvements. I find reading plain old JavaScript painful now, TypeScript really is so much better, and it works really well with Angular.

For moving stuff between controllers, I'd look at something like AmplifyJS or PostalJS, and then use TypeScript to wrap around them to create a strongly typed message bus. Another good way to communicate is via Services and Promises. This method works well for things like modal dialog boxes, where there is a well defined request, and a well defined response. Whereas a message bus should be used for things which don't exactly have a well defined request or response, like events coming in from Websockets, or updating a part of the screen based on a timer.

Thanks, I definitely will look into Amplify and Postal. Factories and Services: it helps differentiate - to me - what is interacting with the backend (Service) what is interacting with the interface (Controller) and what contains miscelaenus methods and storage (Factory). For us everything was wrapped into Services - and not in well designed JS.

As for TypeScript, IMO everyone at my company would benefit from it. I'm really the only one at my company who transcends the front and back end fluently, while it's a unique position (at least here) it can be highly stressful. I'm interested in it because 1) it introduces OO principles to the front end group and 2) can bring to the Java group to the JS world via a somewhat familiar road. I need a couple other people that do what I do elsewise I just do everything myself which has mixed benefits.

I have been slowly refactoring - what I can and am working on - to use, or I guess more accurately return promises (all of our JS is actually wrapped in Services for better or worse), which in that state are more useful for a lot of what we do since other devs just basically do random chaotic poo poo to synchronize stuff.

# ? Nov 2, 2015 03:41

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

geeves posted:

Thanks, I definitely will look into Amplify and Postal. Factories and Services: it helps differentiate - to me - what is interacting with the backend (Service) what is interacting with the interface (Controller) and what contains miscelaenus methods and storage (Factory). For us everything was wrapped into Services - and not in well designed JS.

As for TypeScript, IMO everyone at my company would benefit from it. I'm really the only one at my company who transcends the front and back end fluently, while it's a unique position (at least here) it can be highly stressful. I'm interested in it because 1) it introduces OO principles to the front end group and 2) can bring to the Java group to the JS world via a somewhat familiar road. I need a couple other people that do what I do elsewise I just do everything myself which has mixed benefits.

I have been slowly refactoring - what I can and am working on - to use, or I guess more accurately return promises (all of our JS is actually wrapped in Services for better or worse), which in that state are more useful for a lot of what we do since other devs just basically do random chaotic poo poo to synchronize stuff.

There isn't really a significant difference between Factory and Service. If you are using TypeScript, everything is best done as a Service. Try not to go too far with OO stuff, TypeScript tries to fake things like real inheritance, but JS just plain doesn't support it and it's not worth doing. Use interfaces to provide type checking on your data, but try to avoid that FactoryBuilderProvider hell enterprise Java proscribes.

Most of your important code should be in Services, while your Controllers should simply provide methods to connect data (from Services) to the View. Also, try to avoid putting logic into your template (like using | filter), it's another one of those features which seems cool when making a ToDo app, but I feel ends up making things more confusing in the end, and it costs extra digest cycles.

# ? Nov 2, 2015 03:51

geeves: Sep 16, 2004

Skandranon posted:

There isn't really a significant difference between Factory and Service. If you are using TypeScript, everything is best done as a Service. Try not to go too far with OO stuff, TypeScript tries to fake things like real inheritance, but JS just plain doesn't support it and it's not worth doing. Use interfaces to provide type checking on your data, but try to avoid that FactoryBuilderProvider hell enterprise Java proscribes.

I defintely will keep that in mind. It could change the way we view a service (like I said is currently a thin client - what I didn't say is that it simply handles transactions and goes to our rest api). Interfaces are largely what I had in mind and what I have in mind in developing OO principles, not a complete inquisition to convert OOP

"try to avoid that FactoryBuilderProvider hell enterprise Java proscribes." Noted and I agree, and while not all enterprise Java is like that (we are definitely not), I can understand why some people think that it would be, but to us it's organizing data into semantic, usable and logical constructs.

quote:

Most of your important code should be in Services, while your Controllers should simply provide methods to connect data (from Services) to the View. Also, try to avoid putting logic into your template (like using | filter), it's another one of those features which seems cool when making a ToDo app, but I feel ends up making things more confusing in the end, and it costs extra digest cycles.

So you're suggesting all data transmogrification should happen in the Service and the Controller should only handle the end result? I can get on board with that (for old stuff we are doing that, but for newer stuff the trend was set to do all the logic in the Controller - again something that I've inherited). I've only been using angular since late July so I am still learning best practices, etc. But again thank you much for the tips.

# ? Nov 2, 2015 04:17

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

geeves posted:

So you're suggesting all data transmogrification should happen in the Service and the Controller should only handle the end result? I can get on board with that (for old stuff we are doing that, but for newer stuff the trend was set to do all the logic in the Controller - again something that I've inherited). I've only been using angular since late July so I am still learning best practices, etc. But again thank you much for the tips.

The controller should be concerned with interacting with the user and the template, but not handling important business or infrastructure logic. If you are going to be making HTTP calls, you shouldn't have your controller import $http, you should have a service use $http and encapsulate that information there, and your controllers can then make calls to well defined methods in the service. If you need to persist data that is important, it should be stored in a service of some kind, not passed around controllers.

# ? Nov 2, 2015 04:23

geeves: Sep 16, 2004

Skandranon posted:

The controller should be concerned with interacting with the user and the template, but not handling important business or infrastructure logic. If you are going to be making HTTP calls, you shouldn't have your controller import $http, you should have a service use $http and encapsulate that information there, and your controllers can then make calls to well defined methods in the service. If you need to persist data that is important, it should be stored in a service of some kind, not passed around controllers.

Okay, I think we might be on the same page. I really think that's what we do except where we deal with the returned data. We have no business logic within our controller, just UI. Same with the REST side w/ Jersey, controllers are basically the intermediary to the actual logic (outside of checking permissions, etc.) everything is happening in our REST services API.

As for the front end, the Controller calls Service method returning a Promise. Controller deals with Promise(s) and returned data in conjunction with UI.

As for persisted data, I'll have to mess around with it (there's no 100% correct answer here). Right now with what we're doing data need to be passed around controllers and services. It's similar to what I would use to solve a scope problem with JS just in this different context.

# ? Nov 2, 2015 04:45

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

I may have asked this before and I apologize if I have:
I'm looking to get into this more advanced front-end development, specifically AngularJS. Should I learn 1.X or 2.X? The only experience I have with it is the Shaping Up With Angular.js tutorial which I've all of forgotten at this point anyway. I Know I'd have to 'un-learn' a lot of stuff going from 1 -> 2 ,but I would think 1 would have better resources available.

tl;dr
Should I learn AngularJS 1.X or 2.X?
What resources, like an online course, would be good to learn it?

# ? Nov 16, 2015 15:17

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

The Merkinman posted:

I may have asked this before and I apologize if I have:
I'm looking to get into this more advanced front-end development, specifically AngularJS. Should I learn 1.X or 2.X? The only experience I have with it is the Shaping Up With Angular.js tutorial which I've all of forgotten at this point anyway. I Know I'd have to 'un-learn' a lot of stuff going from 1 -> 2 ,but I would think 1 would have better resources available.

tl;dr
Should I learn AngularJS 1.X or 2.X?
What resources, like an online course, would be good to learn it?

I did some "research" into this (in so much as I googled around a bit) and came away with the idea that 1.x isn't going anywhere for a couple of years at least. TONS of existing projects use 1.x (obviously), and the Angular people have said that they'll support both 1.x and 2.x for the foreseeable future. Therefore you should be fine picking up 1.x now, and try to stick to most of the practices featured in this style guide: https://github.com/johnpapa/angular-styleguide. They'll get you away from relying on $scope for everything, which will be especially useful whenever you start diving into 2.x.

As for resources, Codecademy has a decent Angular course to get you started: https://www.codecademy.com/learn/learn-angularjs

# ? Nov 16, 2015 16:28

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

The Merkinman posted:

Should I learn AngularJS 1.X or 2.X?
What resources, like an online course, would be good to learn it?

I would start with AngularJS 1.X, with an eye for doing things closer to how Angular 2 works. There are a lot of things that have built up in Angular 1.X that are bad, but can be avoided (like using $scope). Only having 2.0 experience would be almost useless right now, whereas there will be 1.X apps to work on for many years to come. Also, take a look at TypeScript, it works well with 1.X, and will get you pretty close to working as if you were using 2.0, and will make the transition fairly smooth when it does happen.

As for good resources for using TypeScript with AngularJS... I've never really found any, it's all in bits and pieces all over. Feel free to PM me any questions though, I've been in the trenches for a year now with the two and feel I've made some significant progress. Just not the blogging type.

# ? Nov 16, 2015 17:29

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Karthe posted:

I did some "research" into this (in so much as I googled around a bit) and came away with the idea that 1.x isn't going anywhere for a couple of years at least. TONS of existing projects use 1.x (obviously), and the Angular people have said that they'll support both 1.x and 2.x for the foreseeable future. Therefore you should be fine picking up 1.x now, and try to stick to most of the practices featured in this style guide: https://github.com/johnpapa/angular-styleguide. They'll get you away from relying on $scope for everything, which will be especially useful whenever you start diving into 2.x.

As for resources, Codecademy has a decent Angular course to get you started: https://www.codecademy.com/learn/learn-angularjs

Skandranon posted:

I would start with AngularJS 1.X, with an eye for doing things closer to how Angular 2 works. There are a lot of things that have built up in Angular 1.X that are bad, but can be avoided (like using $scope). Only having 2.0 experience would be almost useless right now, whereas there will be 1.X apps to work on for many years to come. Also, take a look at TypeScript, it works well with 1.X, and will get you pretty close to working as if you were using 2.0, and will make the transition fairly smooth when it does happen.

As for good resources for using TypeScript with AngularJS... I've never really found any, it's all in bits and pieces all over. Feel free to PM me any questions though, I've been in the trenches for a year now with the two and feel I've made some significant progress. Just not the blogging type.

3rd step in Codecademy tutorial posted:

code:

app.controller('MainController', ['$scope', function($scope) { 
  $scope.title = 'Top Sellers in Books'; 
}]);

I hope you mean $scope is okay in some cases.

If that's the case, thanks. You too Skandranon. I was apprehensive in going with AngularJS 1.X, but now I'm not.

# ? Nov 16, 2015 17:49

Adbot: ADBOT LOVES YOU

# ? May 18, 2024 12:26

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

The Merkinman posted:

I hope you mean $scope is okay in some cases.

If that's the case, thanks. You too Skandranon. I was apprehensive in going with AngularJS 1.X, but now I'm not.

No, it's bad in all cases. This is AngularJSs main weakness, its documentation and literature. Even the good sites out there are still pushing patterns that are obsolete in 1.4 and explicitly done away with in 2.0. Like using $scope for anything other than calling it's special functions.

Do the tutorials, see how it was done way back when, then take a look at things like BindToController and ControllerAs, and see how you never have to use $scope again.

# ? Nov 16, 2015 17:53

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »