|
Thermopyle posted:I read this post about React "Aha!" moments this morning and I thought I'd share it since I remember when I figured these things out it really helped me understand how to write React. Going through the CodeAcademy courses on React and definitely feeling a bunch of AHA moments. These courses are so much better than the Lynda ones omg.
|
#
?
Jan 20, 2017 16:43
|
|
|
|
| # ? May 23, 2024 01:29 |
|
|
Plavski posted:I'm always sceptical of those surveys. Here's one from late last year where Vue barely registers at all: http://stateofjs.com/2016/frontend/
|
|
#
?
Jan 20, 2017 16:51
|
|
|
Got a React-Redux question. The docs mention the concept of presentational vs. container components, whereby one handles how things are rendered and only communicates via callbacks, and the other houses all the logic and maps the props and things. They also mention something about components that fall between the two, where these components have form and function tightly coupled such as input fields. The question I have is, where exactly do forms fall on this spectrum? I'm talking about an entire component that basically represents a whole input form. Right now our approach is that we have a container component that only maps state and dispatch, and the matching presentational component holds a bunch of state, has onChange callbacks defined on it, and bypasses the store by being the component that actually holds the data that's sent to the API to get the output. For that and a few other reasons, I've failed in implementing an Advanced Settings form by the end of the sprint, because it's hard to understand what's going on. Assuming that I want a form thst represents (part of) the app's state, that a user can edit, and that editing updates the store for, how does such a form get split up in React and Redux? Is it heavy on the containers? How dumb are the presentational components? How much do they mix? What also muddies the waters is that much of the output is also used as input as well (  ). Something about defaults assumed by the API.
|
|
#
?
Jan 20, 2017 16:53
|
|
|
Le0 posted:So I managed to advance my list and make it work, thanks! You're beyond my understanding of Spring at this point, but that output from {$list} looks like what you'd get calling ToString on a Java object IIRC. You might have better luck with Spring-specific problems in the Java thread. Sorry :\
|
|
#
?
Jan 20, 2017 16:58
|
|
|
Pollyanna posted:Got a React-Redux question. The docs mention the concept of presentational vs. container components, whereby one handles how things are rendered and only communicates via callbacks, and the other houses all the logic and maps the props and things. They also mention something about components that fall between the two, where these components have form and function tightly coupled such as input fields. Spend the afternoon watching Dan Abromov's Egghead React/Redux videos. You seem to have a tenuous grasp on how React actually works for someone who has been asking questions about it for so long.
|
|
#
?
Jan 20, 2017 17:20
|
|
|
Lumpy posted:Spend the afternoon watching Dan Abromov's Egghead React/Redux videos. You seem to have a tenuous grasp on how React actually works for someone who has been asking questions about it for so long. That seems reasonable. My coworker and I are struggling with the work we need to do due to unfamiliarity with React and Redux, and although I've worked with it in the past it hasn't been to any large degree - and my coworker has barely used JavaScript before. I'll go through those tutorials first and come back when I know more - the PMs are just gonna have to wait.
|
|
#
?
Jan 20, 2017 17:26
|
|
|
Pollyanna posted:That seems reasonable. My coworker and I are struggling with the work we need to do due to unfamiliarity with React and Redux, and although I've worked with it in the past it hasn't been to any large degree - and my coworker has barely used JavaScript before. I'll go through those tutorials first and come back when I know more - the PMs are just gonna have to wait. https://egghead.io/courses/getting-started-with-redux https://egghead.io/courses/building-react-applications-with-idiomatic-redux Better to spend 3 hours learning than spend 100 hours writing code that doesn't work well.
|
|
#
?
Jan 20, 2017 17:29
|
|
|
Le0 posted:
This is the only thing that popped out to me, should the path for the input be newlistName (instead of just 'listName')? Since the path for the task name is just taskName? This might not be the problem, I don't know Spring.
|
|
#
?
Jan 20, 2017 18:52
|
|
|
Lumpy posted:Spend the afternoon watching Dan Abromov's Egghead React/Redux videos. You seem to have a tenuous grasp on how React actually works for someone who has been asking questions about it for so long. Definitely do this. After that, take a look at redux-forms. I've found it makes splitting container and presentation components really easy. It has some things I don't like but it's been the best solution I've found so far.
|
|
#
?
Jan 20, 2017 18:56
|
|
|
I really have no clue how to get Jasmine tests running through Karma for my Angular project that is using Webpack. I feel like that could be the thread title right there for some reason. I am generally unclear about how these all work together since this is my first JavaScript project and I ended up using the lot of these tools based on web recommendations. So I've gotten about as far as a cargo cult can go before I have to learn how this stuff works and why it's there. The situation in particular is that I can't get Karma to run anything against any of my stuff because it can't find any of it. I can run self-contained unit tests just fine, but everything goes to poo poo as soon as I try to reference my application's existence. So stuff like this: code:Then there's stuff like this. If I put my bundle.js in both the preprocess and files section, webpack tries to pack the previous bundle.js. What? The general idea I had is that webpack would create a bundle, and then my unit tests would run against that bundle. Is that not a sane mental model for how all this works? I would assume the bundle could draw upon its dependencies so I wouldn't have to add redundant requirements into the karma configuration. Instead it looks like it's using webpack to pack each test or something and ignoring my bundle. Or something. I am also thinking my problem is that I am both trying to use my bundle and run all this webpack stuff. That would be why it's trying to pack my bundle. Maybe I don't need any of the webpack stuff; just add the bundle in the files section and be done with it. So clearly I have work to do, but I felt the need to complain and hope for a life preserver or something. Today is my DevOps day so I can throw time at this, but hopefully without just banging my head against the wall. I should also probably go through what Webpack does again because it doesn't all stick to me quite yet. HaB posted:ui-grid will do all of that. It's nice and easy to implement, since I just did it. Thanks. I think in the original comparisons I saw, people said it was too complicated for what they wanted. However, what other people isn't necessarily what I want, so I assume I have to step up.
|
|
#
?
Jan 20, 2017 20:31
|
|
|
Rocko Bonaparte posted:unit test stuff. barf. So, when unit testing Angular apps, keep in mind your Angular code has to actually be there, as well as the libraries you are using, like Angular. So you have to load Angular, the code that defines your module, etc, before you start any tests. In your case, it is probably choking on module, as it should be angular.mock.module("moduleName"); This will instantiate your module. You can then start instantiating Services, Controllers, Components, etc, from that module, and executing code against it. To make testing easier, it's a good idea to not put all your code in the same module, as you have to deal with bootstrapping the whole thing at once. It is much easier to have small modules, so you can test them individually.
|
|
#
?
Jan 20, 2017 21:23
|
|
|
One of the things I've always really struggled to wrap my head around whenever I look into modern front-end stuff, is how on earth does this stuff scale to a full-sized app? The guides and tutorials I often come across are so contrived and tend to just throw everything together into one file for the sake of brevity, but I feel like none of them do a very good job of explaining how you should lay out all of your source files and manage the pipeline involved in "building/compiling/transpiling/whatever" and then deploying the app. Does anyone have a good example of a github project, or a tutorial or something that covers this stuff? I'm looking for something a little more "real world" than adding and removing items from a <ul>.
putin is a cunt fucked around with this message at 05:36 on Jan 24, 2017 |
|
#
?
Jan 24, 2017 05:30
|
|
|
I've found that you kinda need to go bigger than tutorials for that stuff. For Aurelia (my framework of choice), Aurelia for Real World Web Applications has a really good chapter on file structure and app organization. It's very much geared around building commercial applications with the framework, so a good structure is key. Likewise, other books on frameworks I've read have similar structure chapters. Investing in a good book for your framework of choice will help you a lot. But I'd also be interested if there are any web pieces on the subject; I've never found any that are particularly useful.
|
|
#
?
Jan 24, 2017 10:14
|
|
|
The Wizard of Poz posted:One of the things I've always really struggled to wrap my head around whenever I look into modern front-end stuff, is how on earth does this stuff scale to a full-sized app? The guides and tutorials I often come across are so contrived and tend to just throw everything together into one file for the sake of brevity, but I feel like none of them do a very good job of explaining how you should lay out all of your source files and manage the pipeline involved in "building/compiling/transpiling/whatever" and then deploying the app. Does anyone have a good example of a github project, or a tutorial or something that covers this stuff? I'm looking for something a little more "real world" than adding and removing items from a <ul>. I can't point you to an article or anything, but I can tell you how I got from tutorial -> real world (at least in Angular 1). So every basic tutorial has all the script in one file. You make app.js and inside that you declare a controller, and a service, and your angular app itself. Obviously not workable for anything greater than one each Controller/Service/etc. The next step up is one file for each type of thing: app.js, controllers.js, services.js, etc. And if you only have maybe 2-3 of each - that might be workable. Points off for maintainability, however. So then a large tutorial will recommend your js/scripts directory be laid out like so: code:The final epiphany: you stop thinking in terms of code, and instead start thinking about what your app actually does and how your code gets you there. So my usual file layout is by function, and using a scripts directory for any code not used by a single function: code:So the biggest caveat here is: needing to maintain your index.html file with all the paths to your app file, BUT. Highly recommended to use Webpack or Grunt/Gulp or something which can handle all that poo poo for you. So I was in the same spot as your a few years back, and I never found a good answer as to how it would scale to a full sized application. All of the above is mostly the result of plenty of trial and error. I've worked in React a bit, and used a similar structure, though instead of function we grouped by Component, since that's React's "atom".
|
|
#
?
Jan 24, 2017 13:25
|
|
|
HaB posted:So I was in the same spot as your a few years back, and I never found a good answer as to how it would scale to a full sized application. All of the above is mostly the result of plenty of trial and error. Yeah I feel like I'm in this situation now. I've just started to build my first CRUD React app and I'm still struggling a bit trying to figure out logically which should be a component and what shouldn't. Guess you just gotta keep practicing
|
|
#
?
Jan 24, 2017 14:38
|
|
|
Grump posted:Yeah I feel like I'm in this situation now. I've just started to build my first CRUD React app and I'm still struggling a bit trying to figure out logically which should be a component and what shouldn't. Every app is different, but for big React apps (I use Redux so that's part of my answer) I wind up with something like this: code:Containers are bread & butter Redux classes that take app state and convert it to props for wrapped components as well as mapping dispatch-able actions to props. I use something close to the "ducks" pattern in my redux tree so each default export is the reducer, and all action creators are in the same file, exported individually as named functions. The index.js at the root of /redux is the reducer combiner. Services are for things that do stuff outside my app like API calls and so on. They always return Promises so they play nice with async actions (I use thunks, but there are other good options as well) Utility holds functions that I use in multiple places grouped together in some way that makes sense on the app in question: string formatting, validation functions, etc. Theme is where I hold common SASS things that are app-wide. All the component .scss files @import the theme.scss one. The styling in here is very minimal, it's basically color variables, font spec, and mixins. This is just what makes sense for me, and has served me well on a bunch of "largish" projects. I got here by having other things not work as well and I kept tweaking as needed. The good / bad thing about React is that it is so not opinionated about most things that the paradox of choice comes into play in many ways.
|
|
#
?
Jan 24, 2017 15:16
|
|
|
Another Real World example where the default setup isn't necessarily the best is js file concatenation. If you serve a lot of repeat users to your site and also tend to modify a small set of your js files, separate bundles can be very helpful where you distinguish which js files are less likely to change (if you can make such a determination) and which you might make changes to frequently, so that a single change in your js doesn't cause a user to pull down all of your js via single concatenated file every time.
|
|
#
?
Jan 24, 2017 17:03
|
|
|
Opulent Ceremony posted:Another Real World example where the default setup isn't necessarily the best is js file concatenation. If you serve a lot of repeat users to your site and also tend to modify a small set of your js files, separate bundles can be very helpful where you distinguish which js files are less likely to change (if you can make such a determination) and which you might make changes to frequently, so that a single change in your js doesn't cause a user to pull down all of your js via single concatenated file every time. ehhhh I'm a little doubtful on this. It would depend greatly on what your caching system is, but my last 2 jobs before this one were GIGANTIC, heavily visited sites (upwards of 50 million/day). A single bundle and blowing away the cache when ANYTHING changes lets me guarantee that all users have the same stuff. A scorched earth approach? Perhaps, but I didn't have to go mucking about with trying to match up the setup someone who reported a bug with a local setup. Grab the same file and I'm off and running. Seems like the approach you listed could lead to some really difficult to track down behavior post production, because something you were certain wouldn't affect anything else got updated and somehow it did. Then again - this all depends on a LOT of factors - size of your site, size of your bundle(s), number of visitors per day, how the site is monetized, etc.
|
|
#
?
Jan 24, 2017 17:11
|
|
|
The Wizard of Poz posted:One of the things I've always really struggled to wrap my head around whenever I look into modern front-end stuff, is how on earth does this stuff scale to a full-sized app? The guides and tutorials I often come across are so contrived and tend to just throw everything together into one file for the sake of brevity, but I feel like none of them do a very good job of explaining how you should lay out all of your source files and manage the pipeline involved in "building/compiling/transpiling/whatever" and then deploying the app. Does anyone have a good example of a github project, or a tutorial or something that covers this stuff? I'm looking for something a little more "real world" than adding and removing items from a <ul>. A lot of this will come down to which framework you're using. Redux is pretty widely accepted to be a necessary part of a React application which will help you with how you structure your application. Read the first page of links you come up with when you google for "React folder structure" and "React redux folder structure". (also use "directory" instead of "folder")
|
|
#
?
Jan 24, 2017 17:12
|
|
|
HaB posted:ehhhh I'm a little doubtful on this. It would depend greatly on what your caching system is, but my last 2 jobs before this one were GIGANTIC, heavily visited sites (upwards of 50 million/day). If you use webpack it can help you with make multiple bundles and since it has already statically analyzed your imports it will cache-bust only the relevant bundles. I personally haven't actually done this, but I know people who have. edit: Since I mentioned webpack, here's a webpack presentation I watched yesterday that might help a person wrap their head around how webpack works and stop using these boilerplate webpack.config.js files.
|
|
#
?
Jan 24, 2017 17:14
|
|
|
Thermopyle posted:If you use webpack it can help you with make multiple bundles and since it has already statically analyzed your imports it will cache-bust only the relevant bundles. Yeah now that I think about it - at CNN we were having webpack generate multiple bundles.
|
|
#
?
Jan 24, 2017 17:32
|
|
|
Since we're on the subject; The Changelog had a very good episode with one of the webpack guys last month.
|
|
#
?
Jan 24, 2017 18:21
|
|
|
I've been going through the Redux tutorials on egghead, and given what I've learned of it, I'm having a tough time understanding the role of lifecycle methods in writing a React-Redux component. Right now, the app I'm working on implements componentWillReceiveProps, shouldComponentUpdate, and componentDidUpdate with code for calling action creator callbacks, changing the state of the component, and limiting when the component should update. The way it's been explained to me is that implementing these lifecycle methods are necessary for using Redux with React, as this is what happens when the global store changes:
Given what I've learned about React and Redux, I was under the impression that you shouldn't be depending on these lifecycle methods at all if possible. Redux propagates changes to the store as props, which should automatically be reflected in components and shouldn't necessitate custom logic in the lifecycle methods. The reason for this approach was explained to me as being a result of needing to share common pieces of state across multiple different components, i.e. all our components need the parameters for submitting API calls, and we need to spread them among the components. I personally feel like there is a way to structure our state tree such that we don't have to take this approach, and I also don't see why this precludes us from getting the state we want independent of which component we are in. I know there's very little that can be said since the actual codebase and use case aren't here to inspect, but I'm not confident in the approach we have. Is there a known reason to do this?
|
|
#
?
Jan 24, 2017 18:31
|
|
|
Pollyanna posted:I've been going through the Redux tutorials on egghead, and given what I've learned of it, I'm having a tough time understanding the role of lifecycle methods in writing a React-Redux component. Right now, the app I'm working on implements componentWillReceiveProps, shouldComponentUpdate, and componentDidUpdate with code for calling action creator callbacks, changing the state of the component, and limiting when the component should update. The way it's been explained to me is that implementing these lifecycle methods are necessary for using Redux with React, as this is what happens when the global store changes: You should be using componentWillReceiveProps and componentDidUpdate rarely if ever. Mostly never. So you are correct in that if you implement Redux in an intelligent way, you should not be using those lifecycle methods. Your application only has ONE place where the state lives: the Redux store. That's it. Components should not need to know anything about API calls or parameters or anything other than "what do I need to draw on the screen". You will often need to see if some piece of state is available: "Did we fetch the list of fart jokes yet?" You can do this in a few ways, but having a fetchedFartJokes property in the part of the state tree that will handle fart jokes is a good way to do this. So when you attempt to render the list, you see that no, you have not! You can do this check by having mapStateToProps check and fire the fetchFartJokes action or by having your container component check in componentWillMount. If you have not fetched yet, the action is fired off, which probably sets fetchingFartJokes to true in your state so you can show a loading indicator by passing that as a prop to the display component. When the (async) action completes, it fires a fartJokesRecieved action, which puts the list in the state and sets fetchedFartJokes and fetchingFartJokes to the appropriate values. Your container sees the new state and passes different props to the component it wraps. Again, the only place application state live is the Redux store. The only way components get access to the state is because they are getting props derived form it via mapStateToProps. EDIT: You use shouldComponentUpdate to tell React that it shouldn't bother checking if a component (and subsequently it's children) needs to be redrawn. You only do this if you are having performance issues, and you have narrowed it down to an expensive redraw where you are 100% certain there doesn't need to be one. Lumpy fucked around with this message at 18:58 on Jan 24, 2017 |
|
#
?
Jan 24, 2017 18:51
|
|
|
Yeah, I had a feeling we were taking an expensive and confusing route. I still do not understand the impetus behind our approach, especially since the crux of the matter seems to depend on accessing the store independently of any particular component since that's what react-redux is for. And the other developer has in fact acknowledged that having everything handled by Redux in the state tree instead of managing individual component state is an option, but we aren't doing it because ?????????. I still don't entirely understand why we're doing what we're doing even though I've asked for an explanation twice, and it's entirely possible that I'm just missing it. I want to say that I don't have much faith in this, but I'm hesitant to simply say "no you're wrong" without really, really understanding what's going on. I want to push back on this, but I'll have to figure out how. With regards to the shared state part, to be specific: quote:If there was very little "shared" state between components, it would be a strong argument for using a component's props, and taking as little state as possible. However, all of the components so far require at a minimum the parameters for a successful API call, and they must be shipped around between components. We use state to do some of that. Alternatively, we could pump all of those parameters through the actions and state. Pollyanna fucked around with this message at 19:24 on Jan 24, 2017 |
|
#
?
Jan 24, 2017 19:13
|
|
|
Pollyanna posted:Yeah, I had a feeling we were taking an expensive and confusing route. I still do not understand the impetus behind our approach, especially since the crux of the matter seems to depend on accessing the store independently of any particular component since that's what react-redux is for. And the other developer has in fact acknowledged that having everything handled by Redux in the state tree instead of managing individual component state is an option, but we aren't doing it because ?????????. I don't know much about this newfangled stuff, but surely the components shouldn't need API parameters? They shouldn't even be aware that an API exists. As for why your other devs are doing what they're doing, is it possible they've fallen into that horrible situation where the boss is after deliverables and no one has been given time to properly learn their poo poo? putin is a cunt fucked around with this message at 20:55 on Jan 24, 2017 |
|
#
?
Jan 24, 2017 20:53
|
|
|
Pollyanna posted:Yeah, I had a feeling we were taking an expensive and confusing route. I still do not understand the impetus behind our approach, especially since the crux of the matter seems to depend on accessing the store independently of any particular component since that's what react-redux is for. And the other developer has in fact acknowledged that having everything handled by Redux in the state tree instead of managing individual component state is an option, but we aren't doing it because ?????????. If your components are making API calls, then your app is not at all using React or Redux remotely in a sane way. Your components can dispatch actions which then make an API call, but in no way shape or form should actually be making calls themselves. Common parameters live in the store, which async action creators have access to, and if there happened to be any component specific needs, they get passed as the payload in the action. That would be an exception rather than a rule though. Sounds like somebody is shoehorning some other frameworks way of doing things onto Redux.
|
|
#
?
Jan 24, 2017 21:00
|
|
|
Lumpy posted:If your components are making API calls, then your app is not at all using React or Redux remotely in a sane way. Your components can dispatch actions which then make an API call, but in no way shape or form should actually be making calls themselves. Common parameters live in the store, which async action creators have access to, and if there happened to be any component specific needs, they get passed as the payload in the action. That would be an exception rather than a rule though. When React came out I think it was pretty common to fetch API stuff in one of your lifecycle methods. I bet what's happening with Pollyanna's codebase is either the codebase started development during the time period where this was acceptable design, or no one making architecture decisions has really updated their skills since first learning React back then.
|
|
#
?
Jan 24, 2017 21:03
|
|
|
This project was started in the past two months and the lead developer has just recently started learning React and Redux. I wish I knew exactly what was wrong with this project, but to put it bluntly: we're an insurance company, and all the rest of our tech is old 1960s COBOL machines. We suck rear end at modern development.
|
|
#
?
Jan 24, 2017 21:26
|
|
|
Pollyanna posted:This project was started in the past two months and the lead developer has just recently started learning React and Redux. I wish I knew exactly what was wrong with this project, but to put it bluntly: we're an insurance company, and all the rest of our tech is old 1960s COBOL machines. We suck rear end at modern development. Given my experience doing consulting work for some local agents: 
|
|
#
?
Jan 24, 2017 21:35
|
|
|
Pollyanna posted:This project was started in the past two months and the lead developer has just recently started learning React and Redux. I wish I knew exactly what was wrong with this project, but to put it bluntly: we're an insurance company, and all the rest of our tech is old 1960s COBOL machines. We suck rear end at modern development. I think I figured it out: Pollyanna posted:... the lead developer has just recently started learning React and Redux. I'd be happy to do a week of
|
|
#
?
Jan 24, 2017 21:39
|
|
|
Lumpy posted:I'd be happy to do a week of No, me first! I'll rewrite it all in Angular2, you'll (I'll) be so much happier with the code ($$$).
|
|
#
?
Jan 24, 2017 21:56
|
|
|
Pollyanna posted:This project was started in the past two months and the lead developer has just recently started learning React and Redux. I wish I knew exactly what was wrong with this project, but to put it bluntly: we're an insurance company, and all the rest of our tech is old 1960s COBOL machines. We suck rear end at modern development. So the obvious question becomes: why are you guys using tech no one understands for a greenfield project?
|
|
#
?
Jan 24, 2017 22:25
|
|
|
The Wizard of Poz posted:So the obvious question becomes: why are you guys using tech no one understands for a greenfield project? Have you *seen* how many github stars it has?
|
|
#
?
Jan 24, 2017 22:45
|
|
|
HaB posted:... Lumpy posted:... Very, very useful stuff, thanks guys. Gives me a place to start!
|
|
#
?
Jan 24, 2017 22:50
|
|
|
The Wizard of Poz posted:One of the things I've always really struggled to wrap my head around whenever I look into modern front-end stuff, is how on earth does this stuff scale to a full-sized app? The guides and tutorials I often come across are so contrived and tend to just throw everything together into one file for the sake of brevity, but I feel like none of them do a very good job of explaining how you should lay out all of your source files and manage the pipeline involved in "building/compiling/transpiling/whatever" and then deploying the app. Does anyone have a good example of a github project, or a tutorial or something that covers this stuff? I'm looking for something a little more "real world" than adding and removing items from a <ul>. Have a look at Ember, and in particular Ember-CLI which describes the project structure and build system. The other frontend frameworks are developing similar tools but Ember's is the oldest and most mature.
|
|
#
?
Jan 24, 2017 23:09
|
|
|
Did a rewatch of Idiomatic Redux this weekend, and then got to start a new module this week. Holy fuuuck everything so much more beautiful and elegant now.  Now if I could just get a free minute to rewrite the last six month's code....
|
|
#
?
Jan 25, 2017 17:02
|
|
|
Don't sweat it. I'm finding one of the understated advantages of React/Redux to be how it readily enables small, iterative refactoring. And even when ill-considered smelly hacks work their way in, they stay relatively isolated so the rot doesn't spread and become idiomatic.
|
|
#
?
Jan 25, 2017 17:27
|
|
|
ynohtna posted:Don't sweat it. Yeah, someone said "easy to shoot yourself in the foot, but easy to grow a new foot" which I think sums it up pretty nicely.
|
|
#
?
Jan 25, 2017 20:42
|
|
|
|
| # ? May 23, 2024 01:29 |
|
|
Is there a best practice when using API calls in a React/Redux based site? I'm trying to get my head around the structure of an idea I have for a personal project to try and learn a more modern way to build a site. It's going to be a site that lets you view upcoming private space launches, I also wanted a user to be able to click on a company name and get more information about them. All data will be stored in Firebase. I'm not to clear on what the logic flow should be, I'm thinking something like this: 1. User visits http://website.com/company/companyName 2. The company component dispatches a "start fetching company data" Redux action, using the companyName as a parameter to search the DB with. 3. The Redux action uses Thunk as middleware to fetch the object holding that companies info from the Firebase DB, then passes that into a "finished grabbing company data" action, which causes the reducer handling that action to update the store, which causes the company component to re render with the new data. Is having the API call logic inside an async redux action a common practice (was planning on having all the API logic in it's own module that exports the specific fetch/update/delete functions, which I import into the redux actions module)? Or is my thinking totally off?
|
|
#
?
Jan 25, 2017 21:59
|
|
