Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Mr Shiny Pants
Nov 12, 2012
So in trying to learn Ember I've decided to do their ToDo MVC tutorial.

Half way in the stuff breaks with the following error:

code:

Error while processing route: todos Cannot read property 'fixturesForType' of undefined TypeError: Cannot read property 'fixturesForType' of undefined

Nice, and I was really looking forward to completing the tutorial. I don't even know where to start in fixing this. :(

Edit: Seems like a new version of Ember data fixes it...... nice!

Mr Shiny Pants fucked around with this message at 16:34 on Feb 9, 2015

Adbot
ADBOT LOVES YOU

Wheany
Mar 17, 2006

Spinyahahahahahahahahahahahaha!

Doctor Rope

Mr Shiny Pants posted:

So in trying to learn Ember I've decided to do their ToDo MVC tutorial.

Half way in the stuff breaks with the following error:

code:

Error while processing route: todos Cannot read property 'fixturesForType' of undefined TypeError: Cannot read property 'fixturesForType' of undefined

Nice, and I was really looking forward to completing the tutorial. I don't even know where to start in fixing this. :(

Edit: Seems like a new version of Ember data fixes it...... nice!

Welcome to Ember.

Mr Shiny Pants
Nov 12, 2012

Wheany posted:

Welcome to Ember.

It gets better doesn't it? please say yes ;)

Wheany
Mar 17, 2006

Spinyahahahahahahahahahahahaha!

Doctor Rope

Mr Shiny Pants posted:

It gets better doesn't it? please say yes ;)

My experience says no, but maybe you "get" the framework better than I do.

Mr Shiny Pants
Nov 12, 2012

Wheany posted:

My experience says no, but maybe you "get" the framework better than I do.

Seeing that I just started using it and already running into this, I would say hardly. :)

Edit: After doing some more research: Maybe I am misunderstanding these frameworks but is it really hard to create something like a drill-down?

Have a top level, click on it, it's child items appear, click on child item and it's child items appear.

This seems like something you would really want, and it looks to be really hard if I look at Backbone relational and all the other frameworks.

Mr Shiny Pants fucked around with this message at 20:31 on Feb 9, 2015

IAmKale
Jun 7, 2007

やらないか

Fun Shoe
I've been running through this AngularJS+Firebase tutorial but the guide is just old enough that its instructions for authenticating against Firebase are now obsolete. I went through the AngularFire API docs and was able to update the tutorial's Auth service to use the new API calls but I'm having an issue feeding errors back to the controller that handles the login/registration forms so I can show the error message to the user.

The tutorial originally says to catch errors in the AuthController and set the error message to a scope variable like this:
code:
$scope.login = function () {
    Auth.login($scope.user).then(function () {
      $location.path('/');
    }, function (error) {
      $scope.error = error.toString();
    });
  };
Then, I just need to set up a <p> element to display the error:
code:
<p ng-show="error" class="text-danger">{{ error }}</p>
Unfortunately after updating the tutorial's Auth service to use the new AngularFire API calls, none of the errors are exposed to the Controller - they're all caught within the service:

code:
'use strict';

app.factory('Auth', ["$firebaseAuth", "FIREBASE_URL", "$rootScope", function($firebaseAuth, FIREBASE_URL, $rootScope) {
	var ref = new Firebase(FIREBASE_URL);
	var auth = $firebaseAuth(ref);

	var Auth = {
		register: function(user) {
			return auth.$createUser({email: user.email, password: user.password})
				.then(function(userData) { Auth.error = ''; })
				.catch(function(error) { Auth.error = error.message; console.log('Authentication failed:', error); });
		},
		login: function(user) {
			return auth.$authWithPassword({email: user.email, password: user.password})
				.then(function(authData) { Auth.error = ''; Auth.user = authData; return authData; })
				.catch(function(error) { Auth.error = error.message; console.log('Authentication failed:', error); });
		},
		logout: function() {
			auth.$unauth();
			Auth.user = {};
		},
		resolveUser: function() {
			return Auth.user;
		},
		signedIn: function() {
			var isSignedIn = !!Auth.user.provider;
			// console.log("returning", isSignedIn);
			return isSignedIn;
		},
		user: {},
		error: ''
	};

	$rootScope.$on('$firebaseAuth:login', function(e, user) {
		console.log('logged in');
		angular.copy(user, Auth.user);
	});
	$rootScope.$on('$firebaseAuth.logout', function() {
		console.log('logged out');
		angular.copy({}, Auth.user);
	});

	return Auth;
}]);
Then, I perform a check in my AuthController to see if the user is logged in. If they aren't then an error occurred so I grab the error from the Auth service:
code:
$scope.login = function() {
	Auth.login($scope.user).then(function() {
		if(Auth.signedIn()) {
			console.log('Redirecting to main page');
			$location.path('/');
		}
		else {
			$scope.error = Auth.error;
		}
	});
};

// Register the user with Firebase, then login as the user, then
// redirect them to the main page
$scope.register = function() {
	Auth.register($scope.user).then(function() {
		if(Auth.error) {
			$scope.error = Auth.error
		}
		else {
			return $scope.login();
		}
	});
};
Right now this works fine - I can see errors when something goes wrong during login or registration. However it feels like I'm doing something wrong. I'm thinking there's probably a better way for services and controllers to communicate with each other but I'm still new to AngularJS so I'm not even sure what I should be looking for to find a more suitable solution.

IAmKale fucked around with this message at 20:52 on Feb 9, 2015

Sedro
Dec 31, 2008

Mr Shiny Pants posted:

Seeing that I just started using it and already running into this, I would say hardly. :)

Edit: After doing some more research: Maybe I am misunderstanding these frameworks but is it really hard to create something like a drill-down?

Have a top level, click on it, it's child items appear, click on child item and it's child items appear.

This seems like something you would really want, and it looks to be really hard if I look at Backbone relational and all the other frameworks.
This is exactly what ember is designed for, with nested routes and outlets

Mr Shiny Pants
Nov 12, 2012

Sedro posted:

This is exactly what ember is designed for, with nested routes and outlets

Thanks, at least I know I am on the right track. I will endure!

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice
I posted this in the Obj-C thread as well, but somebody with access to React Native posted a nice "first impression" piece: : http://jlongster.com/First-Impressions-using-React-Native

neurotech
Apr 22, 2004

Deep in my dreams and I still hear her callin'
If you're alone, I'll come home.

Lumpy posted:

I posted this in the Obj-C thread as well, but somebody with access to React Native posted a nice "first impression" piece: : http://jlongster.com/First-Impressions-using-React-Native

I'm excited to learn React even more now. I can't wait to get my hands on native and mess around with it.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

neurotech posted:

I'm excited to learn React even more now.

You should be, in my mind, it's easily the best of its peers.

Also, you should just go learn it. It's easy to understand, and quick to learn.

neurotech
Apr 22, 2004

Deep in my dreams and I still hear her callin'
If you're alone, I'll come home.

Thermopyle posted:

You should be, in my mind, it's easily the best of its peers.

Also, you should just go learn it. It's easy to understand, and quick to learn.

I've spent the last few months accumulating a whole bunch of reading, tutorials, and examples. I'm aiming to get started next week on some small projects to get my head around it, and I'm really looking forward to it :)

Horn
Jun 18, 2004

Penetration is the key to success
College Slice
Speaking of react, flipboard has released a library that replaces the dom rendering with canvas. I've barely gotten my feet wet with react but between this and the native stuff it seems like the library has a promising future.

Hadlock
Nov 9, 2004

I'm looking at exporting a bunch of data dynamically to a CSV or XML or JSON file (ugh, or sql, I can do that too, extra steps, whatever) from my VM Host and also manually annotate useful html links or accessible network shares to the side. I cycle through a lot of VMs doing testing etc and would like to be able to monitor what's on the network with some custom info. Along with some color coding and general visual organization.

Is there a bootstrap-py looking CSS library or _____ toolbox I can leverage to make CSV file -> HTML 2.0 for me without too much effort? I feel like I'm not breaking any new ground here and is probably a very simple request. Nothing is public facing.

I tried generating a rough draft of data in to Google Docs and then exporting as a web page, the below is a Chrome render of said data, but like most dynamically generated HTML it's unmaintainable garbage. The few google results for my search queries ("convert csv to html") I've gotten back look awful and hacked together by someone running win98 and forced to use console fonts. I'm open to doing this in javascript, ruby, python, whatever etc, or begrudgingly in php.

Hadlock fucked around with this message at 08:13 on Feb 11, 2015

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Horn posted:

Speaking of react, flipboard has released a library that replaces the dom rendering with canvas. I've barely gotten my feet wet with react but between this and the native stuff it seems like the library has a promising future.

I don't have any use for that, but it seems really cool!

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

I've been messing around with Reflux, and I think I like it better than vanilla Flux or Fluxxor.

It gets rid of the concept of the Dispatcher. Actions themselves become event emitters, and stores listen to the actions they're interested in.

Anyway, if anyone is having a hard time wrapping their head around Flux (which isn't terribly surprising as the pattern isn't quite as elegant as React itself), they might want to give Reflux a look.

Here's a blog post that does a bit of summary of the library: http://spoike.ghost.io/deconstructing-reactjss-flux/

Wedge of Lime
Sep 4, 2003

I lack indie hair superpowers.

Thermopyle posted:

I've been messing around with Reflux, and I think I like it better than vanilla Flux or Fluxxor.

It gets rid of the concept of the Dispatcher. Actions themselves become event emitters, and stores listen to the actions they're interested in.

Anyway, if anyone is having a hard time wrapping their head around Flux (which isn't terribly surprising as the pattern isn't quite as elegant as React itself), they might want to give Reflux a look.

Here's a blog post that does a bit of summary of the library: http://spoike.ghost.io/deconstructing-reactjss-flux/

I did spend a little time looking at reflux and it seems to throw away the central point of Flux (the dispatcher) and not really replace it with anything. I see the dispatcher acting almost as a big lock, allowing you to more easily reason about the order of updates your stores when actions occur. As well as ensuring that only one actions is running at once.

Have I totally misunderstood reflux?

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Thermopyle posted:

I've been messing around with Reflux, and I think I like it better than vanilla Flux or Fluxxor.

It gets rid of the concept of the Dispatcher. Actions themselves become event emitters, and stores listen to the actions they're interested in.

Anyway, if anyone is having a hard time wrapping their head around Flux (which isn't terribly surprising as the pattern isn't quite as elegant as React itself), they might want to give Reflux a look.

Here's a blog post that does a bit of summary of the library: http://spoike.ghost.io/deconstructing-reactjss-flux/

I used Reflux on my last hobby project, and I very much liked it. There are definitely some things about "pure" Flux that make me scratch my head. That said, I'm not sure I have a better solution, just that I'm not convinced that is the "best" one.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Wedge of Lime posted:

I did spend a little time looking at reflux and it seems to throw away the central point of Flux (the dispatcher) and not really replace it with anything. I see the dispatcher acting almost as a big lock, allowing you to more easily reason about the order of updates your stores when actions occur. As well as ensuring that only one actions is running at once.

Have I totally misunderstood reflux?

Yeah, this was my objection at first and the reason I didn't use it when I first came across it awhile back.

However, I think I've come around.

I think the way to think about it is that Reflux has a conceptual dispatcher of sorts, you just don't interact with it in any way.

In vanilla Flux, how do your data stores know which actions to care about? A switch statement or the equivalent in the callback you register with the dispatcher which enumerates all the actions the store cares about. In Reflux, your stores know which actions to care about by an init (or the listenables mixin)which enumerates all the actions the store cares about. Either way, you're enumerating all the actions for the store.

Your React components get data from the stores the same way in Reflux as they do with vanilla Flux.

Really though, I think it's still early days for the libraries and patterns evolving around React...

SpaceAceJase
Nov 8, 2008

and you
have proved
to be...

a real shitty poster,
and a real james
I want to jump into React, but should I bother using JSX or does everyone just ditch it?

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

SpaceAceJase posted:

I want to jump into React, but should I bother using JSX or does everyone just ditch it?

I don't really know anyone who doesn't use JSX.

(queue everyone posting they don't)

Stoph
Mar 19, 2006

Give a hug - save a life.
I like JSX. I can give my components to front-end web developers who aren't comfortable with much more than HTML/CSS and they "get it".

I compile on-the-fly with RequireJS and JSX loader plugin so there is no build step in development.

I want to switch to Browserify but this way is just too easy.

bartkusa
Sep 25, 2005

Air, Fire, Earth, Hope
I think you'd be crazy to not use JSX.

It has dumb poo poo (forcing you to use "className" as an attribute, but barely warning you when you use "class"), but so does everything.

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.

Thermopyle posted:

I don't really know anyone who doesn't use JSX.

(queue everyone posting they don't)

Yep, I don't really like jsx at all, that said I barely gave it a chance. I just import the Dom elements I need with destructured assignment in coffescript or es6.

geetee
Feb 2, 2004

>;[
I've seen a bunch of people hate on JSX, but have yet to hear why. React would still be cool without it, but it makes my every day life so much easier with it. Move elements around? No problem! I can't see myself being nearly as efficient if I had to use the code representation.

I tried out reflux on my last project and like it. I used vanilla flux on a few prior projects. It's fine too, but felt too verbose. To me it's just glorified pub/sub with data flowing one way. I'm probably missing some detail, but it seems to work for me.

I'm curious to see where things progress in the coming months. Relay looks neat, but it seems there's a good deal of backend architecture that needs to be in place. Probably not a silver bullet. I've settled on having a lot of pure components that live inside a "container" component that listens to stores. My application is then a bunch of these containers put together. I was happy to hear a couple other places took a similar approach after watching the React conference videos.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

SpaceAceJase posted:

I want to jump into React, but should I bother using JSX or does everyone just ditch it?

Another "I like JSX" person here. It's so much more concise and declarative, which is the whole point of React.

Speaking of React, I watched the react-router talk from ReactConf this AM. Good stuff!

Workaday Wizard
Oct 23, 2009

by Pragmatica
RE: Reflux.
Is there a correct way to use Actions with asyncResult: true?
Defining Action.listen() doesn't sit right with me. I thought the whole point of Actions is to just be dumb signals and let the Stores handle the logic (including API requests etc.).

TildeATH
Oct 21, 2010

by Lowtax

SpaceAceJase posted:

I want to jump into React, but should I bother using JSX or does everyone just ditch it?

It grows on you.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Shinku ABOOKEN posted:

RE: Reflux.
Is there a correct way to use Actions with asyncResult: true?
Defining Action.listen() doesn't sit right with me. I thought the whole point of Actions is to just be dumb signals and let the Stores handle the logic (including API requests etc.).

I'm still figuring out best practices, but the data store I just wrote (literally) has this for an asyncResult: true action:

JavaScript code:
listenables: [PropertyActions],

init() {
    this.property = [];
    this.listenTo(PropertyActions.fetchProperty.completed, "fetchComplete");
    this.listenTo(PropertyActions.fetchUnits.failed, "fetchFailed");
}
Is that any better for you? Or were you asking something else?

edit: I re-read your question, and understand what you were asking better now. My impression is that most of the React/Flux community prefers async requests to be in the actions and your stores to be completely synchronous code.

For example, the vanilla Flux implementation:

JavaScript code:
var PropertyActions = {
  retrieveProperty() {
    console.log("fetching property");
    AppDispatcher.handleViewAction({
      actionType: ActionTypes.LOAD_PROPERTY
    });

    Request.fetch({
      success: function (collection, response, options) {
        AppDispatcher.handleServerAction({
          actionType: ActionTypes.PROPERTY_RECEIVED,
          collection: collection,
          response: response,
          options: options
        })
      },
      error: function (collection, response, options) {
        AppDispatcher.handleServerAction({
          actionType: ActionTypes.PROPERTY_LOAD_ERROR,
          collection: collection,
          response: response,
          options: options
        })
      }
    })
  }
};
So somewhere calls PropertyActions.retrieveProperty(). The action immediately dispatches the LOAD_PROPERTY event so you can display a spinner or whatever. Then the function calls a library to do the AJAX request and dispatches either a success or error event once it is done.

Reflux has several ways of implementing the same idea. Here's one. This pull request implementing the current child actions behavior has two ways.

Are you still uneasy with the idea?

Thermopyle fucked around with this message at 17:57 on Feb 12, 2015

Workaday Wizard
Oct 23, 2009

by Pragmatica
Thanks.

Thermopyle posted:

...
Are you still uneasy with the idea?

To be frank, yes. I am of the opinion that the Store is the only thing that should be concerned about handling state and how to update it. I see updating state using HTTP requests as an implementation detail of the Store.

I am a beginner when it comes to modern js* stuff though so take my opinion with a grain of salt.

*) Last time I played seriously with js it was called JScript, and I was using it to create fancy Active Desktop wallpapers for Win98.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Shinku ABOOKEN posted:

Thanks.


To be frank, yes. I am of the opinion that the Store is the only thing that should be concerned about handling state and how to update it. I see updating state using HTTP requests as an implementation detail of the Store.

I am a beginner when it comes to modern js* stuff though so take my opinion with a grain of salt.

*) Last time I played seriously with js it was called JScript, and I was using it to create fancy Active Desktop wallpapers for Win98.

There's a few problems that come from doing AJAX in the store.

1) The dispatcher only allows one action to be processed at a time. If you fire off an action to download some data, no other actions, including UI actions, will respond.
2) The idea of putting async code in the Store seems simple until you get more than one store and a few actions. Keeping your stores synchronous makes it much simpler to reason about the logic...especially when you're in situations where you need to use waitFor. This stems from the fact that you're avoiding the cascading events that Flux was born to eliminate.
3) You mess with the one-way data flow of Flux if you attempt to solve #2 by calling into actions from your stores.

You can get a lot more discussion about it by googling "flux async store". Pretty much everyone who has developed large applications agree that async goes in your actions.

Workaday Wizard
Oct 23, 2009

by Pragmatica

Thermopyle posted:

There's a few problems that come from doing AJAX in the store.

1) The dispatcher only allows one action to be processed at a time. If you fire off an action to download some data, no other actions, including UI actions, will respond.
2) The idea of putting async code in the Store seems simple until you get more than one store and a few actions. Keeping your stores synchronous makes it much simpler to reason about the logic...especially when you're in situations where you need to use waitFor. This stems from the fact that you're avoiding the cascading events that Flux was born to eliminate.
3) You mess with the one-way data flow of Flux if you attempt to solve #2 by calling into actions from your stores.

You can get a lot more discussion about it by googling "flux async store". Pretty much everyone who has developed large applications agree that async goes in your actions.

I see. Fluxxor's example also had async stuff in the Actions themselves (http://fluxxor.com/guides/async-data.html).

Good thing I asked before wasting too much time.

Thanks again :tipshat:

Wedge of Lime
Sep 4, 2003

I lack indie hair superpowers.

Shinku ABOOKEN posted:

I see. Fluxxor's example also had async stuff in the Actions themselves (http://fluxxor.com/guides/async-data.html).

Good thing I asked before wasting too much time.

Thanks again :tipshat:

Defining a success and fail action of all ajax callbacks is probably one of the stronger parts of the flux architecture, seeing them all grouped together starts to give you a better sense of what your application is really doing. It also starts to become obvious a developer has omitted handling some failure.

We've also been taking this a little further and defining small utility libraries that abstract away our ajax calls and convert the callbacks into actions.

Horn
Jun 18, 2004

Penetration is the key to success
College Slice
Does anyone know of a good tutorial on setting up gulp / broswerify / grunt for react development? I'm a .net dev by trade so this is one large blind spot for me currently. Is there any advantages to choosing one build system over another?

Ochowie
Nov 9, 2007

So I have another boostrap-ui modal question. Is there a way to make the largest modal view wider? I have a large table that I'd like to display in the modal view and it runs off the edge of the window on the right and starts writing in the "blacked out" space. I'm starting to think the modal idea isn't worth it and I should just redirect the user to the appropriate page but if anyone has any ideas I would appreciate it.

Edit: Got rid of the modal approach for now. I think it looks better this way anyways.

Ochowie fucked around with this message at 18:14 on Feb 13, 2015

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Horn posted:

Does anyone know of a good tutorial on setting up gulp / broswerify / grunt for react development? I'm a .net dev by trade so this is one large blind spot for me currently. Is there any advantages to choosing one build system over another?

https://github.com/substack/browserify-handbook

I don't like gulp or grunt as they feel like a system built up from bubblegum, shoestrings, and tin foil.

Not that npm is a super package management system, but it's better, and browserify makes it easy to use npm packages in the browser so I use it as much as I can. I actually use watchify instead of browserify, but everything in that handbook applies the same, watchify just watches your files and rebuilds your bundle as you work, and since it caches, it builds the bundle very quickly.

FWIW, here's what I do with watchify when I'm doing React development:
code:
watchify -v --debug -t [ reactify --es6 --target es5 ] js/main.js -o js/bundle.js

Horn
Jun 18, 2004

Penetration is the key to success
College Slice
Thanks, that looks exactly like what I need to figure this out.

TildeATH
Oct 21, 2010

by Lowtax
Super babby node question: I have an app that points to one api address for the test environment and another for the prod environment. How does one change the app.js to reflect whether it's deployed to test or prod?

ambushsabre
Sep 1, 2009

It's...it's not shutting down!

TildeATH posted:

Super babby node question: I have an app that points to one api address for the test environment and another for the prod environment. How does one change the app.js to reflect whether it's deployed to test or prod?

An environment variable.

Adbot
ADBOT LOVES YOU

Pollyanna
Mar 5, 2005

Milk's on them.


Oh man, I am super pumped for React Native. That looks so goddamn cool.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply