Mark Erikson markerikson

[9:39 PM] suark: A selector is a function that takes only 1 param which is state and it returns data.
[9:40 PM] maladr0it: in my case it can't function with only that information
[9:40 PM] maladr0it: so i should perhaps rethink
[9:40 PM] maladr0it: it needs to know what chat to get messages for
[9:40 PM] acemarke: @suark: a selector can take any number of arguments
[9:40 PM] acemarke: both in general, and with Reselect specifically
[9:41 PM] suark: I thought createselect returns a function that only takes state
[9:41 PM] acemarke: nope
[9:41 PM] acemarke: in fact, it calls all "input selectors" with all the arguments you pass in
[9:41 PM] maladr0it: only taking state sounds very limiting.. perhaps i should read about what selectors actually are used for

[1:11 PM] jswannabe: Question regarding npm. I had a debate last week with someone at work regarding npm update. I don't like running it since the latest updates from 3rd party libs/modules that my webapp might get might break. There is another dev who's on my side. However, there is another dev that likes running npm update. Our boss likes it too and says that we should always get the latest changes from 3rd parties. For me, I'd rather run npm update on a test branch first and if it's been proven not to break our app, that's the time we'll introduce the new version. It's been an ongoing debate for months now, LMAO! How are you folks doing it at work?(edited)
[1:14 PM] acemarke: My personal suggestion would be that you don't just randomly update libs
[1:14 PM] acemarke: I would agree it's better to do it on a test branch first
[1:14 PM] mruzekw: If they respect semver, there shouldn't be breaking changes? I could be wrong
[1:15 PM] acemarke: that's the theory, but in practice, thi

[10:39 AM] infected mushroom: Is this analogy correct?

Can we say that the store in the Redux app is like a database?
mapStateToProps is used to retrive (read) the information from the database where as
mapDispatchToProps is used to write the information in the same database?
[10:59 AM] infected mushroom: Okay, I am confused now

On official docs it says

Actions are payloads of information that send data from your application to your store

[7:50 PM] acemarke: @jon.m : fwiw, I always have learned best when I had a project I was working on, and needed to implement some feature I'd never built before
[7:50 PM] acemarke: nothing motivates you to learn a particular concept or technology like needing it to build a feature
[7:50 PM] acemarke: ie, "learn generators" isn't terribly useful or motivating
[7:51 PM] acemarke: but "I need to make my async code easier to read / build a complex async logic feature, and Redux-Saga requires use of generator functions" is more of a specific motivation
[7:52 PM] acemarke: now, there's nothing wrong with going out and reading up on a specific feature - promises, generators, observables, etc
[7:52 PM] acemarke: always great to have more tools in the toolbox
[7:52 PM] acemarke: but ultimately you need something to apply those tools to
[7:52 PM] CPT: I agree. Having motivation helps
[7:52 PM] jon.m: I keep seeing this TreeHouse commercial on youtube that says a guy g

[8:27 PM] cquill: @acemarke Right, so many portions of the UI will be connected. But does each connected portion typically get its own container component? Seems verbose and redundant to have the following for each CRUD resource: UserList, UserListContainer, UserView, UserViewContainer, UserEdit, UserEditContainer, UserNew, UserNewContainer. Is there a simpler way?
[9:56 PM] acemarke: @cquill : this leads into one of my favorite (?) semi-rants, and one that I apparently need to write down so I can paste it
[9:57 PM] acemarke: A "container" component is simply any component whose primary job is to fetch data from somewhere, and pass that data on to its children
[9:58 PM] acemarke: With Redux, the wrapper components generated by connect are "container" components, since their job is to extract data from the Redux store
[9:58 PM] acemarke: I generally dislike the somewhat-common approach of trying to divide everything into a "components" folder and a "containers" folder
[9:59 P

[11:29 AM] acemarke: @user1 , @user2, @user3 : I've got articles on modals over here: https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#modal-dialogs . (Will have to add that "from scratch" article to the list)
GitHub
markerikson/react-redux-links
react-redux-links - Curated tutorial and resource links I've collected on React, Redux, ES6, and more
[11:29 AM] user4: What's React Fiber
[11:30 AM] user4: Whats up with these " Adverts "
[11:30 AM] user4: kinda of annoying in a way
[11:30 AM] acemarke: "adverts"?
[11:30 AM] user4: lol
[11:30 AM] user4: oh ur real

	import React, {Component} from "react";
	import {connect} from "react-redux";
	import _ from "lodash";
	import { Message } from "semantic-ui-react";
	import {Portal} from 'react-portal';

	import {selectNotifications} from "./notificationSelectors";

	import {dismissNotification} from "./notificationActions";


	// Ampersand-State doesn't mix in Underscore methods the way Backbone.Model does.
	// Technically it could also be done as a standalone mixin, but we'll do that here.
	var modelMethods = ['keys', 'values', 'pairs', 'invert', 'pick', 'omit'];

	// Mix in each Underscore method as a proxy to `Model#attributes`.
	_.each(modelMethods, function(method) {
	State.prototype[method] = function() {
	var args = [].slice.call(arguments);
	args.unshift(this.attributes);

	import {viewFromComponent} from "viewUtilities";

	class MyListComponent extends React.Component {
	render() {
	// serialized Backbone collection
	const {items = [] } this.props;
	// do stuff with items
	}
	}

	class ControlledInputWithInternalState extends Component {
	constructor(props) {
	super(props);

	this.state = {
	isValid : true,
	value : props.value
	};
	}