React Native (feat. Redux) React Native (feat. Redux)

Creating the Sweat Book Root Component Solution Part 2

Check out a free preview of the full React Native (feat. Redux) course:
The "Creating the Sweat Book Root Component Solution Part 2" Lesson is part of the full, React Native (feat. Redux) course featured in this preview video. Here's what you'd learn in this lesson:

Scott continues demonstrating the solution to the first Sweat Book exercise. He explains the actions he created and talks about how they are organized. He also answers a few audience questions about sharing constants between components and global variables.

Get Unlimited Access Now

Transcript from the "Creating the Sweat Book Root Component Solution Part 2" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Scott Moss: Anybody got stuck on anything?
>> Speaker 2: But you're gonna go over your actions folder?
>> Scott Moss: Yeah, I forgot about that. Yeah, so actions, let's see what's in here. What is in here? Man, okay don't look at that. [LAUGH] That shouldn't be in there.
>> Scott Moss: Okay, we'll talk about that.

[00:00:24] Okay, yeah, so what I did here was, it's a nice pattern to have a file where you just keep the constants for your actions, so let me recap. We had an action called ADD_TODO and I kept passing around between the files. So I can just declare it here.

[00:00:41] So I can just declare those action types here in a file, a constant. So here are all the constants for all the actions that I'm gonna have. That way I can just use them everywhere. All right, so I'm writing this string everywhere. I'll just import these variables here, that's all.

[00:00:57] So here are all my action types that I think that we'll have. So maybe we want to change a tab. We wanna actually do that cuz we're gonna have a tab interface. This is what I'll start with all the async actions. So FETCH_CURRENT_WORKOUT will be fired right before we call the server.

[00:01:11] And then FETCH_CURRENT_WORKOUT_COMPLETE will be called after the server response. So every time you see these two sibling actions, you probably can guess that it's going to be like some asynchronous thing. The same thing with ADD_EXERCISE and ADD_EXERCISE_COMPLETE. This is gonna be asynchronous. And then this is the one for the modal, SET_EXERCISE_VISIBILITY.

[00:01:29] So these are just constants. You can call it whatever. Most call them types cuz they're action types. And then in actions, before, we hardcoded the action right inside the dispatch. Where the pattern which we actually wanna use is action creator. Which is just a fancy word for a function that makes an action, that's all it is.

[00:01:49] So there's this plugin or this library that somebody may call it redux-actions which does that for you. It's really not that great. What it does, it just saves you from writing code. All createAction does is it takes the type of the action you want. And then it returns a function for you to pass in the payload.

[00:02:08] That's it, and it creates an object. So what createAction is for redux-actions, all it's gonna do is just do this for us. It's just gonna return an object with a given type, whatever the type is. And it's just gonna put a payload on it for us. And the payload is whatever we pass in here, so visible.

[00:02:28] That's all it's doing. This is a helper method to do it.
>> Scott Moss: So that's what I'm doing here. So I'll just have a function that I can pass true or false to. And this is gonna return createAction. And again, I don't have to put a return keyword here because it's implicit way of using these parentheses here, so implicit return.

[00:02:46] So I'm just returning createAction, which is just an object with a type property of this type and a payload of this value, yes.
>> Speaker 2: Question from the audience. Jessie T asks, with the container folder, do you use a UI folder for those files?
>> Scott Moss: Exactly, so when you start making the UI components which we will.

[00:03:04] In the lesson up next, we're gonna have a UI folder for those UI components. Yes, and don't look at action creators in here. Because this is all the asynchronous stuff that we haven't gotten to yet. I left it in there. Don't look at it. Cool, any questions on this?

[00:03:27]
>> Speaker 2: Do you always use the key payload in your actions?
>> Scott Moss: Yes, so there's this thing called FSA, Flux Standard Action. It's what the react community came up with as far as what the actions should look like. And it describes the action of having a type property, a payload property and an optional error property.

[00:03:50] And then I think there's also an optional meta property. If we wanna pass in specific metadata that isn't the payload. But might have instructions on how to create a new state. So yes, because of that, I use payload. And if you use redux-actions, which I'm using right here, it will attach whatever you pass in as a payload to the payload property.

[00:04:10] It's just a standard way of doing it. I think it's a great way to have that. That way, you can keep, you can swap out, I guess, different flux implementations. Without having to change your action code cuz it's all the same type. So yeah, I use payload. You could use whatever you want, it's totally up to you.

[00:04:27] But it's really nice just to have a standard inside your reducers. And not have to think about like where is the data on this action object? Where is it? Was it action.data, was it action.response? I don't know what it is. If it's always action.payload, then I know what it is.

[00:04:39] It's totally fine, it's just a standard.
>> Scott Moss: Any more questions on this?
>> Speaker 2: Just a comment. It took me a second but I hadn't seen the pattern before where you're on line two. You're importing that file constants and then as types.
>> Scott Moss: Yes.
>> Speaker 2: And I just think it's really cool how you can then use it almost like an unknown from other languages.

[00:05:04]
>> Scott Moss: Yeah, it's exactly right. So I'm saying import everything from that file as a variable type. So it's just creating object types and putting everything in a file on that property, on that object for me. Yeah, or I can import them independently as well because I'm exporting them all independently.

[00:05:22] So the equivalent is also just to export an object here with all these properties on it, you can do that. But then you won't be able to import them. Well, you still can import them individually, too. You'd have to use destructuring. So, yeah, either way, it will totally work.

[00:05:36]
>> Scott Moss: Any other questions?
>> Scott Moss: Is this what everybody got?
>> Speaker 2: Could you explain. I was in the bathroom, but could you explain why the action creators versus these actions?
>> Scott Moss: Yeah, so the reason we wanna use action creators is so that we can abstract the actual creation of the action object away from where we actually dispatch the action.

[00:06:02] Because before, we hardcoded in the object of type and then payload. But if we were to use that action in many places, we have to write that over and over and over again and probably mess up somewhere. So having an action creator is great because this also gives us a chance to do other things.

[00:06:18] Like for instance, let's say this is just a Boolean right here. But let's say the actual payload was just like an object with something else on it. This is where we can modify that before we pass it in to the reducer. So it's a great place to do that.

[00:06:31] So it's really great just to have these action creators versus just hardcoding in an action. You can also just like to store. They're just static actions that take no payload. They're just like one-off actions. You can just store them in variables, too. If you just have an action that was just like export const.

[00:06:49] And the action might be, I don't know, we'll just call it error. This is a random error action that will fire notification. You can just go ahead and say, yeah, it's type ERROR, and that's it. And I can just use this everywhere, right? Because it's not gonna take any payload so you don't need a function.

[00:07:09] And it's just a regular action that does this error thing.
>> Scott Moss: Whoa, I've never seen that. Any other questions?
>> Scott Moss: Nope, all right, cool. So the next thing we're gonna do is talk about the different navigation strategies. Question, yeah.
>> Speaker 2: Unrelated to redux, is there a global object in React Native that we can attach things to similar to window?

[00:07:39]
>> Scott Moss: Okay, I don't know if I should answer that. [LAUGH] Okay, before I answer it, don't do it.
>> Speaker 2: [LAUGH]
>> Scott Moss: Just don't attach to the global. And yes, there is a global object. And the way you can figure it out, I'm just gonna show you how to figure out versus telling you what it is.

[00:07:55] Is if you just go to the debugger,
>> Scott Moss: And you hit debug.js remotely.
>> Scott Moss: And I guess it's debugging.
>> Scott Moss: Here we go. There's our breakpoint there. And if you just go, I don't know, you can go literally anywhere. Let's just go wherever. And if you look, there's a object right here literally called global.

[00:08:29] That's the global, it's called global. It's not this, it's global. So if you wanna attach something as a global, you literally say global dot whatever and it is attached to the global. That's just a CommonJS thing which is what React is using. Cuz it's using Node, which uses CommonJS.

[00:08:44] So a Node in CommonJS, and therefore React Native. Yes, global is the global, but don't attach anything to global. [LAUGH] It's the whole point of modules is to not have globals. Although React Native does provide globals for us. Does anybody here know how Node works?
>> Speaker 2: Nobody knows how Node works.

[00:09:03] [LAUGH]
>> Scott Moss: I'm looking at the source for Node for a year. And the way they actually inject the globals into Node is actually each module by first this file as a module is actually wrapped in the IIFE, right? So each module is just a function like this.
>> Scott Moss: And then what they do is they pass in all these globals to the functions so you have access to them.

[00:09:28] So like module, require, dirname, global, all this is passed in. So that's why you have access to them magically. But that's really what it's doing. It's just creating an IIFE for you. So yes, global is a global and that's just an object that they pass around to every single module.

[00:09:50] But don't use it. Please don't use it. I know it sucks like importing all the time, like ugh, I gotta import all this stuff. But it's declarative. If you use globals, it's imperative, and now you don't know what's going on. And then you're like, I gotta make sure I load this file first cuz it's got the global stuff.

[00:10:07] And then it's just really bad. Just don't do it.