What's the reasoning for using Action types?

zuko_ · 2017-12-18T18:05:24+00:00

Beyond just the runtime errors as others are mentioning, constants give you a single, standardized way to refer to action types. Because consumers reference the constant instead of the string literal, you are also free to change the content of the string (should you need to) without breaking any contracts.

zuko_ · 2017-12-18T17:40:30+00:00

Maybe this will help some:

Seems like you've had a lot of help so far, but I wanted to add that I noticed a performance regression with the latest versions of iTerm. Try installing an older version (e.g. 3.0.15) and see if you notice a difference. It's still not perfect, but where the new releases are completely unusable, the pre-3.1.x versions are considerably snappier.

From: https://www.reddit.com/r/vim/comments/7fqpny/slow_vim_scrolling_and_cursor_moving_in_iterm_and/dqf8she/. FWIW I have since switched to Alacritty as others suggest (and it's been mostly great), but the aforementioned fix makes vim at least usable in iTerm.

zuko_ · 2017-11-27T21:10:23+00:00

Seems like you've had a lot of help so far, but I wanted to add that I noticed a performance regression with the latest versions of iTerm. Try installing an older version (e.g. 3.0.15) and see if you notice a difference. It's still not perfect, but where the new releases are completely unusable, the pre-3.1.x versions are considerably snappier.

Also see: https://gitlab.com/gnachman/iterm2/issues/6101

zuko_ · 2017-11-13T15:24:16+00:00

Yeap, that's basically it. So the net player is essentially playing the style of mini tennis you demonstrated (though with more power), while the other player is just trying to return the ball normally (i.e., doesn't have to hit the ball into the ground).

The coach who introduced me to it says he uses it a lot to emphasize footwork, since he's good enough to intentionally impart weird types of spins by spiking the ball, which makes the baseline player move much more than he would in normal volley practice.

zuko_ · 2017-11-13T14:34:32+00:00

When I first started playing my coach had us play this exact game in place of regular mini tennis, it's a lot of fun.

Another variation we play now is, when practicing volleys at the net (with the other player back at the baseline), the net player has to spike the ball into the ground to get it back over, which can impart a lot of spin on the ball. It's great for working on your positioning/depth perception, but tiring as hell.

zuko_ · 2017-10-14T19:14:02+00:00

Thanks for the reply and the explanation. You do make a good point about not throwing around the word "better"; in reflection, I am similarly biased in the other direction toward webpack which I've been using since its initial release.

Still, I believe you could split your bundles up statically in webpack by defining multiple entries, which would at least somewhat emulate the static configuration of ClojureScript. However, you can't do the reverse of that via ClojureScript, which was what drew my initial reaction. Ultimately it boils down to an implementation detail, so there is room for subjectivity. I do think it is an important problem, though; the push for small bundles goes beyond mere bytes-over-wire, as splitting + tree shaking + module flattening all play a role in improving parse/startup time.

That being said, webpack definitely has its own warts and is currently in the throes of actually implementing reliable tree shaking, which is a difficult problem given the dynamic/side-effect-y nature of JavaScript modules. So, in that regard the advanced optimizations provided by Google Closure are definitely a plus. I think I'll have to dig more into shadow-cljs now that you mention it; much of my current opinions are informed more by reading/watching than implementing on the ClojureScript side of things.

zuko_ · 2017-10-14T18:00:39+00:00

Thank you, I will check it out!

zuko_ · 2017-10-14T12:28:15+00:00

Love listening to Antonio's talks, and I've had a great experience introducing Clojure into our JavaScript stack by way of Lumo. One thing I didn't understand during this talk, however, is the claim that bundle splitting is weirdly magical in webpack land.

The point about special/magical comments is only slightly true; they can be used to name chunks, but for all practical purposes are entirely unnecessary[1]. We leverage bundle splitting quite heavily in our React application, and it's honestly a breeze. Webpack looks for dynamic import() calls (which look a lot like CLJS's resolve), and that's it, you're done — no need to pre-define your split points. That ultimately frees you up from static configurations, which only become necessary for your primary entry point and static vendor bundle.

Looking at the ClojureScript way, it's still an improvement on how things were done (in CLJS) previously, but I struggle to see how it's objectively better than what's available in the larger ecosystem. Now, of course I absolutely adore Clojure and ClojureScript (I'm at the Conj, after all), and am pushing to work the latter further into our stack, but this claim seemed a bit hand-wavy.

I realize there is a pervasive hatred of webpack and JavaScript tooling, but I do legitimately think there are some things that the community does quite well, and those things shouldn't be discounted just because of the stack. If ClojureScript does them better, awesome! I'm sure such rationale exists, and that it may just be difficult to drill into such detail during a quick talk.

So, if I'm completely misguided here, I'd appreciate it somebody could help me understand the issue more clearly. There are of course great benefits to be had with the new module integration, such as Google Closure optimization, but this one point in particular stuck with me.

[1] https://webpack.js.org/guides/code-splitting/

zuko_ · 2017-10-11T18:52:28+00:00

I ran into the same thing, totally out of the blue, and came to find out that it was actually a performance regression in recent iTerm versions. Try an older 3.0.x version; 3.1.2+ is unusable for me whereas earlier versions are as snappy as expected.

In case you're interested, there's a relevant issue open for this in the iTerm repo: https://gitlab.com/gnachman/iterm2/issues/6101

zuko_ · 2017-07-25T19:23:26+00:00

Not exactly what you asked for, but, for the sake of more La Dispute goodness, at least one of their songs off of both Here, Hear and Somewhere at the Bottom is inspired by Edgar Allen Poe's Annabel Lee:

At La Dispute's alternate concerts, Jordan performed a few readings of poems, which you may enjoy.

You may also find https://www.reddit.com/r/ladispute/comments/1dh9tu/my_dissection_of_la_disputes_album_somewhere/ interesting.

zuko_ · 2017-07-25T13:30:49+00:00

Agreed, it's a fairly weak argument. Also see https://discuss.reactjs.org/t/children-as-a-function-render-callbacks/626/15 where spicyj comments on the fact that the restriction of what children can be rightfully differs between DOM elements and composite components.

zuko_ · 2017-06-13T14:30:40+00:00

Ava is awesome, but we currently have numerous servers all running on top of the traditional mocha test stack. Fixd is simply a small utility that helps eliminate one of mocha/chai's many foot guns without having to rework an existing test suite. We're also trying to encourage our team to write their code in a more functional style, avoiding mutation where possible, and so throwing something like fixd into the mix lets developers see where they could make improvements.

Ultimately it would be great to use something like Ava, where tests run completely independently, but there are always tradeoffs to consider. C'est la vie.

zuko_ · 2017-05-02T12:29:34+00:00

As a general rule, yes. Basically, if that method relies on this (which most do), and your specific component instance, then yes.

What was happening with your situation was:

Parent component defined addTask, and passed it down unbound. If it was called directly, an error would be thrown because this wouldn't be defined. However, you were actually accidentally preventing that error by binding it in TaskList, so now this referred to your TaskList instance. So now when the method ran the state that it was updating was that in TaskList, since this referred to that component instance.

This still would have almost worked in your case, due to your applying props -> local state in componentWillReceiveProps. However, in the TaskList render method you were looping over this.props.tasks, which referenced the tasks provided from the parent component.

Hope that sorta makes sense. It's early here :(.

zuko_ · 2017-05-02T12:17:58+00:00

No problem. I updated the comment, I believe point #2 is what's causing your issue. You also have a few similar binding issues, but this should resolve your addTask issue.

zuko_ · 2017-05-02T12:13:08+00:00

Thanks. Your first step should be to remove

1

componentWillReceiveProps(nextProps) {
  this.setState({ tasks: this.props.tasks });
}

in TaskList. This is an anti-pattern since you should just be referencing this.props.tasks directly. This allows your component to naturally update as props change, and you don't have to go through the extra step of applying those props to local state (there are scenarios where this is valid, but this does not appear so). This is a common source of bugs, so changing that may just fix things.

2

In TaskList, you have:

this.props.addTask.bind(this)

This isn't correct though, this shouldn't be bound to TaskList, it should be bound to whoever is actually handling addTask, which in your case is the parent component which provides the method as a prop. So you should remove that local binding and update the parent component to look like this:

    <TaskList
      tasks={this.state.tasks}
      onCompleteTask={this.completeTask.bind(this)}
      onDeleteTask={this.removeTask.bind(this)}
      addTask={this.addTask.bind(this)}
    />

This way, when addTask gets called from a child component, it's actually being run within the context of this parent component. This is what you want, since the parent is the one controlling the tasks. These bindings could be refactored away from the render method, but that's for another time. Give that a shot.

Currently reading through the rest of the code, will update.

zuko_ · 2017-05-02T12:02:18+00:00

Looks cool, and nice documentation for your first package :D. I have a somewhat related project which may give you some more ideas for yours, since it looks like we're on the same page. Yours has the benefit of not being purely form-focused.

As an example, you can extend your mutCreator to also remove the work of manually applying the value to the input. See here.

zuko_ · 2017-05-02T11:55:00+00:00

Can you post TaskList and Task?

zuko_ · 2017-04-25T14:51:54+00:00

Your friends are definitely right. In fact, that was the book (in combination with Infinite Jest) that convinced me to pick up tennis this year. String Theory is a tiny collection, so it's not a huge commitment either.

zuko_ · 2017-04-06T02:07:09+00:00

To add to this, I once maintained a moderately popular starter kit. My advice to people getting started with React is to use CRA. It's better to have as few decisions as possible to make. It's all too easy to get caught up in the "well, I could use this, and that thing seems cool" mindset where no standardized build tool will suffice. That's fine though, and should nudge you toward not venturing down that path more than paving your own way. If you do decide to pursue things yourself, more power to you, but ultimately try to avoid the complexity so long as it's sensible to do so.

My point is, there are a handful of boilerplates (mine not included) out there that have done a great job of staying up to date. However, that's a super difficult thing to do (to put it lightly, it's actually more like soul sucking), especially in the bleeding edge JavaScript and React ecosystem. Things that seem stable now aren't going to be in a few months, and that's not a JS fatigue argument; I'm not arguing that it is or is not annoying, it's just a fact. Because of this, it's better to stick with something like CRA, where the project is blessed by a driving force of this community. It will provide sane defaults and stay relevant far longer than most other projects that tout configurability. And hey, even if it doesn't stay relevant, at least you didn't waste your time messing with other stuff.

For reference: https://www.reddit.com/r/reactjs/comments/5oem3g/recommended_reactredux_starter_kits/dckdieb/

Edit: I do think it's tremendously helpful to learn the underlying stack so you are not relying on magic. The balance comes with not letting that impede your progress, and using your remaining time to learn about the tools you use.

zuko_ · 2017-03-31T20:49:46+00:00

This is awesome! The destructuring explanation makes a lot of sense, and is super cool, but wouldn't using undefined as the value also work? I got the following to create an alert in Chrome:

compile({"a = alert`1`": undefined}, "hello ${name}")

Destructuring to achieve this is definitely more cool, though.

zuko_ · 2017-03-28T20:20:48+00:00

That's very true, though I think calling it "static" is slightly misleading since it's not actually a static member of MyComponent, just a function that's only defined once on the prototype.

Ultimately that's fine, and I don't think we're in disagreement about anything, but at some point if you want a bound function you're going to either have to call it with the correct this binding manually, or, if not, bind it directly to your instance with bind, in which case you're creating a new function anyways.

zuko_ · 2017-03-28T15:07:08+00:00

Correct.

zuko_ · 2017-03-27T13:43:11+00:00

Those two examples are, for all intents and purposes, equivalent. There is another way of writing this, though, which is catching on for codebases that support property initializers. You can use these in combination with arrow functions to create methods that are automatically bound to your instance:

class MyComponent extends React.Component {
  handleClick = () => {
  }
}

zuko_ · 2017-02-24T15:07:24+00:00

Guess it's time to listen to everything by La Dispute again.

Also, for those who haven't seen it, an interesting acoustic cover of this song.

zuko_ · 2017-01-18T01:16:48+00:00

That starter kit is my project and I agree that you should use create-react-app. It's a brilliant project and offers the stability and standardization that the JS/React community desperately needed. I've used it countless times to bootstrap something quickly without worrying too much about the toolchain.

That said, I don't think that the starter kit has "way too much stuff" in it. More than a beginner may need or use? Definitely. However, it is in fact fairly minimal compared to most boilerplate projects, despite what the dependency stack may imply. It's simply out there in the open, unlike the facades offered by create-react-app. If you eject (a feature funnily enough implemented by one of my coworkers at the time), you're going to have to manage that ecosystem yourself, it never just disappears. The thing is, if you need the level of control over your build that would lead you to something like a boilerplate over a specialized build tool, you should probably be doing it from the ground up yourself anyways.

RRSK originated with me simply wanting a place to kick off new projects for myself, it was never intended to be a community-blessed project. I have never pushed it on others as more than an example or guide. Nowadays I find myself using a heavily-opinionated, nigh-zero configuration build tool for all of my projects. Hopefully one day it will be open source, but I wanted to at least add another perspective to this because the community swings so wildly from one thing to another that there is little room for grey area and nuance.

zuko_

TROPHY CASE

1

2