Until you eject you are unable to configure webpack or babel presets.
\nPresentational components are concerned with how things look. They generally receive data and callbacks exclusively via props. These components rarely have their own state, but when they do it generally concerns UI state, as opposed to data state.\nContainer components are more concerned with how things work. These components provide the data and behavior to presentational or other container components. They call Flux actions and provide these as callbacks to the presentational components. They are also often stateful as they serve as data sources.
\nClass components allows you to use additional features such as local state and lifecycle hooks. Also, to enable your component to have direct access to your store and thus holds state.\nWhen your component just receives props and renders them to the page, this is a ‘stateless component’, for which a pure function can be used. These are also called dumb components or presentational components.
\nIn HTML, form elements such as input html element, textarea html element, and select html element typically maintain their own state and update it based on user input. When a user submits a form the values from the aforementioned elements are sent with the form. With React it works differently. The component containing the form will keep track of the value of the input in its state and will re-render the component each time the callback function e.g. onChange is fired as the state will be updated. An input form element whose value is controlled by React in this way is called a “controlled component”.
\nA higher-order component is a function that takes a component and returns a new component. HOC’s allow you to reuse code, logic and bootstrap abstraction. The most common is probably Redux’s connect function. Beyond simply sharing utility libraries and simple composition, HOCs are the best way to share behavior between React Components. If you find yourself writing a lot of code in different places that does the same thing, you may be able to refactor that code into a reusable HOC.
\nState is similar to props, but it is private and fully controlled by the component. State is essentially an object that holds data and determines how the component renders and behaves.
\nThe state is a data structure that starts with a default value when a Component mounts. It may be mutated across time, mostly as a result of user events.\nProps (short for properties) are a Component’s configuration. They are received from above and immutable as far as the Component receiving them is concerned. A Component cannot change its props, but it is responsible for putting together the props of its child Components. Props do not have to just be data - callback functions may be passed in as props.
\nBecause this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state.
\ncomponentWillMount lifecycle method - this is most commonly used for App configuration in your root component.componentDidMount lifecycle method - here you want to do all the setup you couldn’t do without a DOM, and start getting all the data you need. Also if you want to set up event listeners etc. this lifecycle hook is a good place to do that.componentWillReceiveProps lifecycle method - this lifecycle acts on particular prop changes to trigger state transitions.shouldComponentUpdate lifecycle method - if you’re worried about wasted renders shouldComponentUpdate is a great place to improve performance as it allows you to prevent a rerender if component receives new prop. shouldComponentUpdate should always return a boolean and based on what this is will determine if the component is re rendered or not.componentWillUpdate lifecycle method - rarely used. It can be used instead of componentWillReceiveProps on a component that also has shouldComponentUpdate (but no access to previous props).componentDidUpdate lifecycle method - also commonly used to update the DOM in response to prop or state changes.componentWillUnmount lifecycle method - here you can cancel any outgoing network requests, or remove all event listeners associated with the component.componentDidMount is where an AJAX request should be made in a React component. This method will be executed when the component “mounts” (is added to the DOM) for the first time. This method is only executed once during the component’s life. Importantly, you can’t guarantee the AJAX request will have resolved before the component mounts. If it doesn’t, that would mean that you’d be trying to setState on an unmounted component, which would not work. Making your AJAX request in componentDidMount will guarantee that there’s a component to update.
\nIn JSX expressions that contain both an opening tag and a closing tag, the content between those tags is passed to components automatically as a special prop called props.children.\nThere are a number of methods available in the React API to work with this children prop. These include React.Children.map, React.Children.forEach, React.Children.count, React.Children.only, React.Children.toArray
render(){\n return( \n <div>\n <h1> Hello World from Edureka!!</h1>\n </div>\n );\n}Refs are used to get reference to a DOM node or an instance of a component in React. Good examples of when to use refs are for managing focus/text selection, triggering imperative animations, or integrating with third-party DOM libraries. You should avoid using string refs and inline ref callbacks. Callback refs are advised by React.
\nThe basic idea of redux is that the entire application state is kept in a single store. The store is simply a javascript object. The only way to change the state is by firing actions from your application and then writing reducers for these actions that modify the state. The entire state transition is kept inside reducers and should not have any side-effects.
\nThe store is a javascript object that holds application state. Along with this it also has the following responsibilities:\nAllows access to state via getState()\nAllows state to be updated via dispatch(action)\nRegisters listeners via subscribe(listener)\nHandles unregistering of listeners via the function returned by subscribe(listener).
Actions are plain javascript objects. They must have a type indicating the type of action being performed. In essence, actions are payloads of information that send data from your application to your store.
\nA reducer is simply a pure function that takes the previous state and an action, and returns the next state.
\nRedux thunk is middleware that allows you to write action creators that return a function instead of an action. The thunk can then be used to delay the dispatch of an action if a certain condition is met. This allows you to handle the asynchronous dispatching of actions.
\nfork and takeEvery?Reference - https://stackoverflow.com/questions/42938520/redux-saga-when-to-use-fork
\nQuestion
\nWhat would be the difference between the two approaches below? When do I need to use fork and when not?
\nexport function* watchLoginUser() {\n yield takeEvery(USER_LOGIN, loginUser)\n}\nexport function* watchLogoutUser() {\n yield takeEvery(USER_LOGOUT, logoutUser)\n}\nexport function* watchGetParties() {\n yield takeEvery(PARTIES_GET, getParties)\n}\nexport default function* root() {\n yield [\n fork(watchLoginUser),\n fork(watchLogoutUser),\n fork(watchGetParties)\n ]\n}export default function* root() {\n yield [\n takeEvery(USER_LOGIN, loginUser),\n takeEvery(USER_LOGOUT, logoutUser),\n takeEvery(PARTIES_GET, getParties)\n ]\n}Answer
\nIn general, fork is useful when a saga needs to start a non-blocking task. Non-blocking here means: the caller starts the task and continues executing without waiting for it to complete.
There is a variety of situations where this can be useful, but the 2 main ones are:
\nYour top-level saga can be an example of the first use-case. You’ll likely have something like:
\nyield fork(authSaga);\nyield fork(myDomainSpecificSaga);\n// you could use here something like yield [];\n// but it wouldn't make any difference hereWhere authSaga will likely include things like:
yield takeEvery(USER_REQUESTED_LOGIN, authenticateUser);\nyield takeEvery(USER_REQUESTED_LOGOUT, logoutUser);You can see that this example is equivalent to what you suggested, calling with fork a saga yielding a takeEvery call. But in practice, you only need to do this for code organisation purposes. takeEvery is itself a forked task, so in most cases, this would be uselessly redundant.
An example of the second use-case would be something like:
\nyield take(USER_WAS_AUTHENTICATED);\nconst task = yield fork(monitorUserProfileUpdates);\nyield take(USER_SIGNED_OUT);\nyield cancel(task);You can see in this example that the monitorUserProfileUpdates will execute while the caller saga resumes, and gets to wait to the USER_SIGNED_OUT action to be dispatched. It can in addition keep a reference to it in order to cancel it when needed.
For the sake of completeness, there is another way to start non-blocking calls: spawn. fork and spawn differ in how errors and cancellations bubble from child to parent saga.
Keys help React identify which items have changed, are added, or are removed. Keys should be given to the elements inside the array to give the elements a stable identity. The best way to pick a key is to use a string that uniquely identifies a list item among its siblings. Most often you would use IDs from your data as keys. When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort. It is not recommend to use indexes for keys if the items can reorder, as that would be slow.
\n{\n \"singleQuote\": true,\n \"arrowParens\": \"always\",\n \"printWidth\": 100\n}arrowParens - Include parentheses around a sole arrow function parameter.
singleQuote - Use single quotes instead of double quotes.Following could be used to print out to the console when tests are not passing when you expect them to.
\nconst wrapper = shallow(<Book title=\"Huckleberry Finn\" />);\nconsole.log(wrapper.debug());Below gets outputs to console
\n<div>\n <h1 className=\"title\">Huckleberry Finn</h1>\n</div>.update() could be used to force a re-render in component. Useful to run before checking the render output if something external may be updating the state of the component somewhere.
NOTE: can only be called on a wrapper instance that is also the root instance.
\nclass ImpureRender extends React.Component {\n constructor(props) {\n super(props);\n this.count = 0;\n }\n\n render() {\n this.count += 1;\n return <div>{this.count}</div>;\n }\n}const wrapper = shallow(<ImpureRender />);\nexpect(wrapper.text()).to.equal('0');\nwrapper.update();\nexpect(wrapper.text()).to.equal('1');import { mount } from 'enzyme';\n\nimport ExampleComponent from './ExampleComponent';\n\njest.mock('../../../../services/api/index.js', () => ({\n serviceConnector: (apiName) => {\n const response = {\n getUsers: {\n status: 'SUCCESS',\n users: [\n {\n id: 1,\n name: 'User 1'\n },\n {\n id: 2,\n name: 'User 2'\n }\n ]\n },\n getOrders: {\n orders: [\n {\n id: 1,\n name: 'Order 1'\n },\n {\n id: 2,\n name: 'Order 2'\n }\n ]\n }\n };\n\n return new Promise((resolve, reject) => {\n if (\n apiName === 'api/get-users'\n ) {\n return resolve(response.getUsers);\n } else if (\n apiName === 'api/get-orders'\n ) {\n return resolve(response.getOrders);\n } else {\n return reject(new Error('No response Found'));\n }\n });\n }\n}));\n\ndescribe('ExampleComponent', () => {\n // By passing the done function here, we’re telling Jest to wait until the done callback is \n // called before finishing the test. See Testing Asynchronous Code docs for more details.\n it('fetches data from server when server returns a successful response', async (done) => {\n // We invoke Enzyme to mount render, which also invokes the React lifecycle methods\n \n const onUsersLoaded = jest.fn();\n const exampleComponent = mount(<ExampleComponent onUsersLoaded={onUsersLoaded} />);\n\n // Press a button in the component which triggers get-users API request.\n await exampleComponent\n .find(Button)\n .at(2)\n .props()\n .onClick();\n // Wait for component to rerender\n exampleComponent.update();\n\n const expectedUsers = [\n {\n id: 1,\n name: 'User 1'\n },\n {\n id: 2,\n name: 'User 2'\n }\n ];\n\n // Wrapping our assertion code inside a process.nextTick() ensures that the functions \n // queued in the current event loop are completed, thus also ensuring that our Promises \n // and other code inside ExampleComponent is done executing.\n process.nextTick(() => {\n expect(onUsersLoaded).toHaveBeenCalledWith(expectedUsers);\n // We invoke done to tell Jest that this test case is complete.\n done();\n });\n });\n});