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 »

xpander: Sep 2, 2004

I'm working with Backbone and Coffeescript(very new to both), and am trying to figure out access a collection once it's fetched. Scrubbed code below:

code:

class window.SomeView extends Backbone.View

  initialize: ->
    @someCollection = @options.someCollection
    @var = @method(@someCollection)
    @anotherMethod(@someCollection)

  method: (collection) ->
    _.size(collection)

  anotherMethod: (collection) ->
    @anotherVar = new 3rdParty.Extension.SomeClass(collection)

This is fairly straightforward. I'm not actually trying to simply get the size of the collection, but it's part of the process. method is returning 0. I gave anotherMethod as an example of what is working elsewhere - when the collection is passed into a class constructor, it seems to be working. I'm assuming that Backbone is smart enough to wait until the collection is fetched and not execute instantly. So my questions is, how do I do the same? I'm familiar with the asynchronous nature of JS and ajax calls, but I don't know how to force it to wait on a collection being fetched/ready.

# ? Apr 30, 2015 18:59

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 17:57

hedgecore: May 2, 2004

You want to listen to the collection for the 'sync' event, then trigger your method calls after. Though it might make more sense to fetch the collection in the code that normally creates that view instead. On a successful fetch, create that view, and then you know the fetched collection will be available.

You could also instantiate a promise (like $.Deferred()) on initialize, resolve it on parse, and use $.when().then() to run code once it's resolved.

# ? Apr 30, 2015 21:55

xpander: Sep 2, 2004

hedgecore posted:

You want to listen to the collection for the 'sync' event, then trigger your method calls after. Though it might make more sense to fetch the collection in the code that normally creates that view instead. On a successful fetch, create that view, and then you know the fetched collection will be available.

You could also instantiate a promise (like $.Deferred()) on initialize, resolve it on parse, and use $.when().then() to run code once it's resolved.

Listening to the sync event worked pretty much instantly. Thank you!

# ? Apr 30, 2015 22:41

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

I'm starting an academic program in a week where I'll have ~40 or so classmates whose course loads and schedules overlap almost entirely for about 16 months. I intend to take/publish course notes via github pages and I'm looking for advice in establishing a workflow that A) enables me to write documents in real time (eg, taking notes) and B) makes peer collaboration from the rest of the group as easy as possible.

For A), I'm pretty comfortable with quickly banging out raw html with emmit shortcuts and snippets, and I had originally thought that I would go this route. For B), I'm thinking that I can put together a tutorial workflow for Atom or VSCode (cross platform and git integration seem necessary here).

Now I'm looking at Jekyll and I expect that it may be the appropriate tool simplify parts of this process. Does Jekyll comb files to produce 'reports' out of the box? Eg, could it produce todo.html (and todo.json) by combing all files for instances of

code:

<div class="assignment">
 <div class="date">
 </div>
</div>

? After the fact, can it recognize manual changes to todo.json as being 'authoritative' and propogate them back to their respective sources? Can html and markdown be mixed in a single file?

Do any of you have experience with a 'live blogging' workflow? Are there more appropriate tools that I'm not considering?

# ? May 5, 2015 18:20

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

To anyone playing with jspm - what's the "proper" way of incorporating browser-only React into a project?

My first guess was to do a "jspm install react" but that installs the npm module and all the dependencies. Opposed to something like moment where you do "jspm install moment" and you're good to go with a single file. Are you supposed to include the module and all the dependencies and then have gulp look for the dist file and throw that into a build directory or something? That seems like an annoying workflow, so I ended up just downloading react.min.js and loading it manually. What's the point of using a package manager if I have to do that, though?

# ? May 6, 2015 18:14

TheOtherContraGuy: Jul 4, 2007; brave skeleton sacrifice

Hey I just inherited a bunch of old HTML4 emailers. I want to spruce them up but I also heard that CSS is only partially supported on some email clients. What are the guidelines for using CSS in emails?

# ? May 6, 2015 20:08

bartkusa: Sep 25, 2005; Air, Fire, Earth, Hope

TheOtherContraGuy posted:

Hey I just inherited a bunch of old HTML4 emailers. I want to spruce them up but I also heard that CSS is only partially supported on some email clients. What are the guidelines for using CSS in emails?

IIRC, don't. Use inline styles. Srsly.

The only email clients with good style support are on mobile phones. Web mail is universally awful.

I got a lot of use out of Litmus for email testing.

# ? May 6, 2015 20:14

TheOtherContraGuy: Jul 4, 2007; brave skeleton sacrifice

bartkusa posted:

IIRC, don't. Use inline styles. Srsly.

The only email clients with good style support are on mobile phones. Web mail is universally awful.

I got a lot of use out of Litmus for email testing.

Thanks, I'll check Litmus out.

# ? May 6, 2015 20:35

Boosh!: Apr 12, 2002; Oven Wrangler

TheOtherContraGuy posted:

Thanks, I'll check Litmus out.

If I need a newsletter out ASAP I code something up real quick and use this inliner: http://zurb.com/ink/inliner.php

# ? May 6, 2015 21:19

Mezzanine: Aug 23, 2009

So, I want to get started with React and I think I've got the concepts of how to use it, but I'm not sure if the structure I'm envisioning is the "React way" to do this.

Example:
I want to make a submission form with components that affect other components. I start with a class for the form itself, and in the "render" section it would have a <form> filled with the individual parts, or groups of parts. I would then make classes for each of the parts (NameField, EmailAddressField, etc) and the collection-type parts (RadioGroup, DateAndTimeField, etc). Finally, I would add the main form class to my page, which would then generate the fields inside.

Is this the right way to start? If so, how would I tell one field to affect the other? Do any components that affect each other have to be included in some kind of "container" component in order to be able to reference each other? I'm just so used to using jQuery and referring to things with a combination of ids, classes and searching through child elements.

Sorry to be so abstract. I tend to just dive in and figure out what works, but that's gotten me in trouble with Ruby and other languages because I never learned the more efficient and clear ways to do some things, and I want to get started with React on the right foot.

Mezzanine fucked around with this message at 15:38 on May 10, 2015

# ? May 10, 2015 15:35

WORLDS BEST BABY: Aug 26, 2006

Mezzanine posted:

So, I want to get started with React and I think I've got the concepts of how to use it, but I'm not sure if the structure I'm envisioning is the "React way" to do this.

Starting with forms in React can be a bit confusing because you want to share the state of components at the bottom with other components in the hierarchy. And to do that, it seems like that state would have to go back up the component hierarchy, which is particularly un-React-like. Ideally you want data to always be flowing down your component hierarchy from a single source of truth at the top in the form of immutable props.

React has both controlled and uncontrolled form elements, and in controlled elements (which are preferred) the field always displays its value prop. So you need to capture user input yourself, and have it modify the value passed to the value prop. This sounds like a lot of work for changing the value in a text field, but capturing and managing the values of forms yourself can make common jobs like validation a lot easier in the end.

On the React docs they first suggest that you create functions in parent components that are then passed down to their child components as props. The child components then use the passed down function to return user input back to the parent component. This is all right for quick hacks, but it becomes hard to manage once your forms start increasing in complexity. At the bottom of that documentation page they briefly talk about using a global event system instead, and it's a shame they don't go further into it because it's the ideal solution for something like this.

With a global event system, your can make your form fields report user input right back to the top of the hierarchy, where an object representing all the state in your form can be modified and then passed back down the hierarchy as immutable props. This is great, because there's now only one stateful component in your form, which will make developing and debugging it a whole lot easier. I can recommend PubSubJS for something like this.

Also, consider that some of your form fields (NameField, EmailAddressField) have very similar jobs and may be easy to merge into a single TextField component that can take validation/format errors as props. React really shines when you have highly reusable components available!

WORLDS BEST BABY fucked around with this message at 17:08 on May 10, 2015

# ? May 10, 2015 17:05

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

WORLDS BEST BABY posted:

Starting with forms in React can be a bit confusing because you want to share the state of components at the bottom with other components in the hierarchy. And to do that, it seems like that state would have to go back up the component hierarchy, which is particularly un-React-like. Ideally you want data to always be flowing down your component hierarchy from a single source of truth at the top in the form of immutable props.

React has both controlled and uncontrolled form elements, and in controlled elements (which are preferred) the field always displays its value prop. So you need to capture user input yourself, and have it modify the value passed to the value prop. This sounds like a lot of work for changing the value in a text field, but capturing and managing the values of forms yourself can make common jobs like validation a lot easier in the end.

On the React docs they first suggest that you create functions in parent components that are then passed down to their child components as props. The child components then use the passed down function to return user input back to the parent component. This is all right for quick hacks, but it becomes hard to manage once your forms start increasing in complexity. At the bottom of that documentation page they briefly talk about using a global event system instead, and it's a shame they don't go further into it because it's the ideal solution for something like this.

With a global event system, your can make your form fields report user input right back to the top of the hierarchy, where an object representing all the state in your form can be modified and then passed back down the hierarchy as immutable props. This is great, because there's now only one stateful component in your form, which will make developing and debugging it a whole lot easier. I can recommend PubSubJS for something like this.

Also, consider that some of your form fields (NameField, EmailAddressField) have very similar jobs and may be easy to merge into a single TextField component that can take validation/format errors as props. React really shines when you have highly reusable components available!

Also, once you start looking at using a global event system, you might as well go ahead and just implement Flux. I'm liking reflux a lot lately, but there's multiple other implementations as well as just using Facebook's own Dispatcher and rolling your own.

# ? May 10, 2015 18:00

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

PubSub is a really bad road to go down IMO, for things like form data. The way I see it, if you don't have enough weight to warrant using a flux architecture, there's a root component of the form right, build a pure JavaScript state manager object/class thing that gets instantiated at that root component.

The state manager keeps the data inside using Immutable JS (http://facebook.github.io/immutable-js/docs/) and has a few methods for changing that data. When a change happens it sends the data to the root component that gets propagated down the tree, along with methods that can change that data.

Immutable is good because it makes all the change checks just by using referential equality, which is fast as hell. It also allows you to do cute stuff, for example in order customisation if changing an option would effect the price in a non trivial way, you can calculate after every single step so each button could bear the price change underneath it quite simply.

Bit long story short, don't bury the state in your components, get something separated out that contains your state data and contains all the methods for interacting with that state. Keep it isolated entirely from a React component at first so its just pure JS with simple libraries. From there it'll be easier to figure out how you should pass the data and methods around.

# ? May 10, 2015 18:55

WORLDS BEST BABY: Aug 26, 2006

Thermopyle posted:

Also, once you start looking at using a global event system, you might as well go ahead and just implement Flux. I'm liking reflux a lot lately, but there's multiple other implementations as well as just using Facebook's own Dispatcher and rolling your own.

Flux is great, but I thought it might learning about the dispatcher/actions/stores might overkill for someone just getting their bearings with React. I like Flummox a lot myself! Though I wonder whether Flux is going to enjoy the same amount of momentum when Relay finally comes round.

Maluco Marinero posted:

Bit long story short, don't bury the state in your components, get something separated out that contains your state data and contains all the methods for interacting with that state. Keep it isolated entirely from a React component at first so its just pure JS with simple libraries. From there it'll be easier to figure out how you should pass the data and methods around.

Yeah, this is much better! It�s just a little thing, but would you pass the state manager to components further down the hierarchy via props, or use something like context?

WORLDS BEST BABY fucked around with this message at 19:41 on May 10, 2015

# ? May 10, 2015 19:32

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

WORLDS BEST BABY posted:

Yeah, this is much better! It�s just a little thing, but would you pass the state manager to components further down the hierarchy via props, or use something like context?

I wouldn't, contexts aren't official API yet, so you'd be better off just using props. Something like (snippets from existing code):

Trivial state manager with all the complex stuff stripped out:

code:

module.exports = function(component, initial) {
  var data = Immutable.Map(initialData);
  var getData = function() { return data };
  // call data.toJS() if you want a standard javascript object rather than immutable data returned

  var updateComponent = function() {
    component.updateFormData(getData());
  };

  var doThing = function(key, val) {
    data = data.set(key, val);
    updateComponent();
  };

  return {
    getData: getData,
    doThing: doThing
  }
}

code:

import State from "./FormState.js";

module.exports = React.createClass({
  updateFormData: function(newData) {
    this.setState({formData: newData});
  },

  getInitialState: function() {
    var state = State(this, this.props.initialData); //we're passing the component to the state manager here
    return {
      formState: state,
      formData: state.getData()
    };
  }
  // render code
});

So for any child, pass them this.state.formState as a property, and if doThing is called it will update the data down the tree. You can also just pass formState's functions if you like, it'll still work just fine.

Maluco Marinero fucked around with this message at 00:26 on May 11, 2015

# ? May 10, 2015 20:03

Mezzanine: Aug 23, 2009

Thanks, everyone! Having the state of the form separated from the components sounds like a good way to start. I'm sure I'll have more questions as I go.

# ? May 10, 2015 23:58

waffle enthusiast: Nov 16, 2007

Is there a way to cache certain API requests in Angular? My app provides a list of cities that I want to put in my navbar: `[Denver, Austin, Boston, ...]`. Users can then click on a city and get a list of drop-in hockey venues/dates/times. Ideally, I'd like to populate this navbar and every city's content from the API exclusively. But the navbar data gets refreshed every time the user reloads or changes endpoints (e.g. clicks from Home to Denver). That seems like a lot of calls back to the API just to get a list of cities.

My solution so far has been to hard code the list of cities in the navbar code ($scope.cities = ['Denver', 'Austin', 'Boston',...]), which isn't too bad, but I wonder if there's a better or more idiomatic way. In a perfect world, I'd be able to add a new city (and venues) to the database and have users automatically see it.

I'm at work, so I don't have any code samples at the moment, but I'm hoping someone can put me on the right track.

waffle enthusiast fucked around with this message at 18:54 on May 12, 2015

# ? May 12, 2015 18:52

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

Dangerllama posted:

Is there a way to cache certain API requests in Angular? My app provides a list of cities that I want to put in my navbar: `[Denver, Austin, Boston, ...]`. Users can then click on a city and get a list of drop-in hockey venues/dates/times. Ideally, I'd like to populate this navbar and every city's content from the API exclusively. But the navbar data gets refreshed every time the user reloads or changes endpoints (e.g. clicks from Home to Denver). That seems like a lot of calls back to the API just to get a list of cities.

My solution so far has been to hard code the list of cities in the navbar code ($scope.cities = ['Denver', 'Austin', 'Boston',...]), which isn't too bad, but I wonder if there's a better or more idiomatic way. In a perfect world, I'd be able to add a new city (and venues) to the database and have users automatically see it.

I'm at work, so I don't have any code samples at the moment, but I'm hoping someone can put me on the right track.

If you have your API calls abstracted out to an external service (should do this anyways), you can then have that service manage a cache instead of always actually making the call. So something like if (hasAlreadyBeenLoaded) resolvePromiseViaCache else resolvePromiseViaAPICall. Your consumers still need to treat the call as a promise, even if resolving from the cache is in fact synchronous.

# ? May 12, 2015 20:36

waffle enthusiast: Nov 16, 2007

Oh, I think I understand. So rather than putting logic in my controllers like

code:

# NavbarController

$scope.cities = $http.get(�cities endpoint�) {
  // http logic
}

I should do something like

code:

# NavbarController
$scope.cities = somePromiseService.fetchAListOfCities();

# Some Promise Service 
exports.fetchAListOfCities = function() {
  if (cached) {
    return the cached list
  }
  else {
    $http.get(�cities endpoint�) and also cache it
  }
}

This makes much more sense than what I was thinking about. Thanks.

# ? May 12, 2015 20:52

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

Kind of. Your service should be returning promises to your controller, so it can handle accordingly. So in your service, if it's cached, you can use the $q Angular service to create a promise that you resolve immediately. Something like the following.

code:


if (isCached) {
    	var defer = $q.defer();
	defer.resolve(cachedCities);
	return defer.promise;
}
else {
	return $http.get(�cities endpoint�) and also cache it
}

# ? May 12, 2015 21:01

waffle enthusiast: Nov 16, 2007

Yeah, makes sense. I've got some reading to do about promises, but it seems pretty straightforward. Thanks for your help.

# ? May 12, 2015 21:18

MrMoo: Sep 14, 2000

Dangerllama posted:

Is there a way to cache certain API requests in Angular?

The sledgehammer approach would be to use HTML5 service workers which pretty much replaces HTML5 appcache because that was rather cumbersome to utilize.

MrMoo fucked around with this message at 22:38 on May 12, 2015

# ? May 12, 2015 22:34

Spraynard Kruger: May 8, 2007

Skandranon posted:

Kind of. Your service should be returning promises to your controller, so it can handle accordingly. So in your service, if it's cached, you can use the $q Angular service to create a promise that you resolve immediately. Something like the following.
code:
if (isCached) {
    	var defer = $q.defer();
	defer.resolve(cachedCities);
	return defer.promise;
}
else {
	return $http.get(�cities endpoint�) and also cache it
}

Fun fact, you can also use $q.when to simplify this a bit:

code:

if (isCached) {
	return $q.when(cachedCities);
}
...

# ? May 12, 2015 23:43

waffle enthusiast: Nov 16, 2007

I wound up consolidating it like so. Since the $http service has its own caching layer, I didn't have to worry about an if/else. Not sure if this is idiomatic but it seems to work (boilerplate from angular-fullstack:service):

code:

'use strict';

angular.module('dropinApp')
  .service('cityService', function ($http, $q) {
    // AngularJS will instantiate a singleton by calling "new" on this function
    this.getCities = function() {
      var defer = $q.defer();

      $http.get('/api/cities', { cache: true }).
        success(function(data) {
           defer.resolve(data);
        });

      return defer.promise;
    };
  });

# ? May 13, 2015 15:36

Spraynard Kruger: May 8, 2007

Dangerllama posted:

I wound up consolidating it like so. Since the $http service has its own caching layer, I didn't have to worry about an if/else. Not sure if this is idiomatic but it seems to work (boilerplate from angular-fullstack:service):
code:
'use strict';

angular.module('dropinApp')
  .service('cityService', function ($http, $q) {
    // AngularJS will instantiate a singleton by calling "new" on this function
    this.getCities = function() {
      var defer = $q.defer();

      $http.get('/api/cities', { cache: true }).
        success(function(data) {
           defer.resolve(data);
        });

      return defer.promise;
    };
  });

This is an anti-pattern with promises, since you're just going to be left hanging if an error happens, your promise will never resolve.

code:

'use strict';

angular.module('dropinApp')
  .service('cityService', function ($http) {
    // AngularJS will instantiate a singleton by calling "new" on this function
    this.getCities = function() {
      return $http.get('/api/cities', { cache: true });
    };
  });

Here's some other anti-patterns, it's from a different promise library, but the concepts are still the same. Bottom line, don't use $q.defer() unless you really know what you're doing. https://github.com/petkaantonov/bluebird/wiki/Promise-anti-patterns#the-deferred-anti-pattern

Spraynard Kruger fucked around with this message at 15:52 on May 13, 2015

# ? May 13, 2015 15:47

waffle enthusiast: Nov 16, 2007

Now I'm wholly confused. You guys were just telling me to use promises for this. I see that I'm not resolving in case of an $http error, but now you're telling me not to do the thing you just told me to do :confused:

So�just farm out the $http call to a service that can cache the data�don't use promises?

# ? May 13, 2015 17:19

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

Dangerllama posted:

I wound up consolidating it like so. Since the $http service has its own caching layer, I didn't have to worry about an if/else. Not sure if this is idiomatic but it seems to work (boilerplate from angular-fullstack:service):
code:
'use strict';

angular.module('dropinApp')
  .service('cityService', function ($http, $q) {
    // AngularJS will instantiate a singleton by calling "new" on this function
    this.getCities = function() {
      var defer = $q.defer();

      $http.get('/api/cities', { cache: true }).
        success(function(data) {
           defer.resolve(data);
        });

      return defer.promise;
    };
  });

The other issue is you are relying entirely on the $http caching mechanism (which is fine if that's what you want). If you want to implement your own strategy (cache expires every 5 minutes, except on leap years when there is a blood moon), you will have to do it manually.

Dangerllama posted:

Now I'm wholly confused. You guys were just telling me to use promises for this. I see that I'm not resolving in case of an $http error, but now you're telling me not to do the thing you just told me to do

So�just farm out the $http call to a service that can cache the data�don't use promises?

You have to be using promises as $http is returning promises. If you are using $scope.cities = $http.get, Angular is automatically unwrapping that promise for you and making it look like $http.get actually returns a value. It doesn't, it returns a promise that should be handled. Using $q.when() like Spraynard suggested is probably the best way to do what you want.

Skandranon fucked around with this message at 17:24 on May 13, 2015

# ? May 13, 2015 17:21

waffle enthusiast: Nov 16, 2007

Alright, I'm going to go on a vision quest to figure this poo poo out.

# ? May 13, 2015 17:42

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

It helps if you think in terms of understanding the ES6 promise spec (this stuff is core JavaScript now) and treat the different libraries out there as implementation details. Here is some documentation:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

You almost always want to use the foolproof way (new Promise) like this when wrapping/promisifying callback APIs manually:

code:

var serviceMethod = function () {
    return new Promise(function (resolve, reject) {
        doAsyncThing(function (err, data) {
            if (err) {
                return reject(err);
            }
            resolve(data);
        })
    });
};

Or even better, libraries like Bluebird add functions like Promise.promisify.

# ? May 13, 2015 18:08

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

Stoph posted:

Or even better, libraries like Bluebird add functions like Promise.promisify.

Bluebird is one of a small handful of libraries that I consider essential for almost any project I work on, for anyone looking to get their feet wet with promises. Others being things like lodash, moment, numeral, etc.

Speaking of, does anyone like a specific library for replacing jQuery's $.ajax and $.getJSON?

# ? May 14, 2015 04:09

Depressing Box: Jun 27, 2010; Half-price sideshow.

Helicity posted:

Speaking of, does anyone like a specific library for replacing jQuery's $.ajax and $.getJSON?

I just started using it, but SuperAgent seems good so far.

# ? May 14, 2015 04:30

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Helicity posted:

Bluebird is one of a small handful of libraries that I consider essential for almost any project I work on, for anyone looking to get their feet wet with promises. Others being things like lodash, moment, numeral, etc.

when.js has even better flow control facilities than Bluebird IMO, with roughly identical (great) performance.

# ? May 14, 2015 07:01

M31: Jun 12, 2012

Helicity posted:

Speaking of, does anyone like a specific library for replacing jQuery's $.ajax and $.getJSON?

Fetch api polyfill? https://github.com/github/fetch

# ? May 14, 2015 08:03

Kekekela: Oct 28, 2004

Helicity posted:

Speaking of, does anyone like a specific library for replacing jQuery's $.ajax and $.getJSON?

I've been using request.

# ? May 14, 2015 09:58

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

To be honest I've always found wrappers lacking in one way or another, whether its tracking progress, reliably parsing the body based on content type, not swallowing exceptions on a CORS error, I've always found something that shits me whether it's reqwests, jQuery, requests.
I'd love to find a library that works but at this point xhr is actually trivial to write and well supported for modern dev, so I'd rather just do that and avoid the gaps in APIs.

I dunno, I just never find it a big deal to write a comms wrapper for the app, that way even if you use a library it's trivial to swap it out.

# ? May 14, 2015 10:19

PlaneGuy: Mar 28, 2001; g e r m a n
e n g i n e e r i n g; Yam Slacker

I rolled my own, because Mulaco's right. it's so easy you could tailor one to whatever your thought process is

# ? May 14, 2015 15:16

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

Helicity posted:

Speaking of, does anyone like a specific library for replacing jQuery's $.ajax and $.getJSON?

window.fetch is coming soon to browsers near you. There's a decent polyfill but it might be easier just to use XHR directly until all the dependencies (like window.Promise) are standard too.

# ? May 14, 2015 20:09

Ochowie: Nov 9, 2007

I've been out of this thread for a while and I'm wondering if there are any good tutorials for React/Flux that involve building a non-trivial example app.

# ? May 21, 2015 21:49

yoyomama: Dec 28, 2008

I remember following this: http://tech.pro/blog/2020/a-thrown-to-the-wolves-hands-on-introduction-to-react

I found it more helpful to follow than some of the usual todo app examples.

# ? May 22, 2015 19:13

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 17:57

Ochowie: Nov 9, 2007

yoyomama posted:

I remember following this: http://tech.pro/blog/2020/a-thrown-to-the-wolves-hands-on-introduction-to-react

I found it more helpful to follow than some of the usual todo app examples.

This looks good thanks. When I learned Angular it was pretty easy to see the default structure for the various components but a lot of the React tutorials I've seen have the code right in the HTML file which can't be the right way to go. Also is jQuery the most common way to interact with backend services or are there better options?

# ? May 22, 2015 22:08

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

«‹›235 »