I'm trying to get the componentWillReceiveProps hooks equivalent:
componentWillReceiveProps(newProps){
if(newProps.errors){
this.setState({errors:newProps.errors})
}
}
i think you should use useEffect in react hooks its better to go with hooks
Related
I'm trying to understand the best practice for importing rxjs operators
It seems like I should import share this way, but, the following doesn't work because it says share expects 0 arguments. I'm not quite sure how to call share correctly.
import { share } from 'rxjs/operators';
...
public currentUser: Observable<User> = share(this.currentUser$.asObservable());
Doing it the old way causes no problems. However I seemed to have read that's not the preferred way to import https://www.learnrxjs.io/concepts/operator-imports.html
import 'rxjs/add/operator/share';
...
public currentUser: Observable<User> = this.currentUser$.asObservable().share();
How should I call share if I'm using the recommended way of importing?
Using share is like any other "pipable" operator since RxJS 5.5:
import { share } from 'rxjs/operators';
...
this.currentUser$.pipe(share());
For more details about pipable operators see: https://github.com/ReactiveX/rxjs/blob/master/doc/pipeable-operators.md
However be aware that importing from rxjs/operators imports this entire file https://github.com/ReactiveX/rxjs/blob/master/src/operators/index.ts.
This means that if you bundle your app yourself it might grow in size significantly.
So you might want to import each operator from it's own file like:
import { share } from 'rxjs/internal/operators/share';
... and then use it the same way.
This isn't always necessary. If you're using a preconfigured build system like angular-cli it does path mappings for you so you don't need to worry about it and always use rxjs/operators. You can read more about this:
https://github.com/ReactiveX/rxjs/issues/3018
https://github.com/ReactiveX/rxjs/blob/master/doc/pipeable-operators.md#build-and-treeshaking
In RxJs 5.5 onwards, RxJs introduce Pipeable (or lettable) operators. Read in details here: https://github.com/ReactiveX/rxjs/blob/master/doc/pipeable-operators.md
In short, using the below way is good in Rxjs 5.5 especially if you are using typescript.
import { share } from 'rxjs/operators';
Your first way of importing import { share } from 'rxjs/operators' is wrong because that is just importing the share operator class not the method operator.
In the second example import 'rxjs/add/operator/share' this is correct because it is saying I would like to add the share operator to my observable.
There's also letable operators in rxjs 5.5 like Chybie says but for your use case number 2 is correct.
I'm wondering which technique is best to improve a React application's performance. I learned about the Component lifecycle methods componentWillReceiveProps and shouldComponentUpdate but I'm not really sure which one I should ideally implement to avoid unwanted re-rendering.
So is it best to implement both or just one of them?
Also, I don't understand why shouldComponentUpdate receives the nextProps if componentWillReceiveProps already (should) handle(s) those.
Use PureComponent instead of Component when you need behavior described in your question. https://reactjs.org/docs/react-api.html#reactpurecomponent
componentWillReceiveProps(props) {
console.log("componentWillReceiveProps");
return false; // This will not terminate further control flow in this component.
}
shouldComponentUpdate(props, newState) {
console.log("shouldComponentUpdate");
return false; // This terminates further control flow in this component.
}
Based on condition you can return boolean value from the shouldComponentUpdate method. If you are returning false it will not call the componentWillUpdate() method.
So I have made a simple Json search application that you can view on codepen. It searches the Json title and tags and returns any matches:
http://codepen.io/ghozt12/pen/LVaxLM
It is based off of the example given on the React website (https://facebook.github.io/react/docs/thinking-in-react.html).
However I do not understand where to put the logic that filters the search results. If React is just the V in MVC, shouldn't the business logic go in the Model? But React is just the view, so where do you put the logic?
Specifically for my application, I placed the search code in this react class and I wanted to know if this was the correct place to put it? (see my codepen for detailed view).
var Table = React.createClass({
render: function() {
// CODE THAT FILTERS SEARCH RESULTS GOES HERE
// creates rowTitle array
return (
<div>
{rowsTitle}
</div>
);
}
});
As you said, React is just the V in the MVC. So, where do you put your business logic?
For small, view-specific business logic, it's ok to put that on the component, as you did. If the business logic is in the component, it's going to be on an event-handler, in the render or any other component method.
If you have non-view-specific business logic, and it runs on the client (or both on the client and server), it's always a good practice to isolate that on a separate JavaScript module. React does not play nice with AMD, so you are better off not using RequireJS for modularization. You should probably use Browserify or Webpack. In this case, all you would have to do is add this to the top or your component file: var myBusinessLogic = require('./myBusinessLogic'). Now you can delegate processing to this module. This is the prefered way, because JavaScript modules are easily testable using Jest, Jasmine, Karma or Mocha.
There's also a third scenario in which you delegate business logic to the server. You can directly make Ajax calls to the API on the server, to do this processing, or you can go with the more sophisticated way and use Flux. There's a plethora of Flux implementations out there, like Alt, Redux and Fluxxor. I prefer to have my own implementation of Flux using the default Dispatcher. Within the ActionCreators I call a method on the clientApi (a JS module), which does an Ajax call using Axios to the server. This call is handled by an Express route which finally delegates the business logic to the serverApi.
EDIT: I just moved to Redux :)
I know this answer is late but wanted to add my thoughts. Usually you want to keep presentation components dumb. Meaning your UI components have no logic other then something like a type which may style the component differently. It’s a good idea to pull your logic out into react hooks then using the react hooks in your controlling component. That way all the logic is in your hooks and not in your presentational components making them a lot more independent and reusable.
You can push logic inside every class Component and the App Component. Logic in class Component for this state and Logic in App Component for all Application
Whenever I modify a relationship (many to many) I want to do another action. As far as I know this can't be done using event listeners (see https://github.com/laravel/framework/issues/2303). This works,
function setUserGroups($ids){
$this->groups->sync($ids);
doSomethingElse();
}
The downside is that it's not intuitive for other developers to remember to use this function. Generally I'm able to attach behavior to change in other attributes using mutators, defining them as guarded or adding events, and I just want to be able to do something similar with syncing/attaching.
I don't see creating a repository as a solution for this. We're not using the repository pattern in our application and honestly I see this issue coming up there as well.
You may register your custom event handlers and listeners:
// register listener
Event::listen('user.groupsModified', 'User#onGroupsModified');
Event Handler:
// Handle event in User class
function onGroupsModified($event)
{
}
Then fire the event in setUserGroups function:
function setUserGroups($ids){
$this->groups->sync($ids);
// Fire the event
Event->fire('user.groupsModified');
}
This way, you can abstract the dependency from the setUserGroups method, now you only need to fire the event and no need to know the handler's name.
How do I expose events to my plugin users?
I know that I should use:
$('#myPluginDiv').trigger('eventName', ["foo", "bar"]);
to trigger the event but I'm looking for best practices describing how to declare and invoke events in plugins.
I think you can inspect some of the most used plugins and make your own assumptions. We have no standards on this, just code convention.
Colorbox (source: https://github.com/jackmoore/colorbox/blob/master/jquery.colorbox.js) defines a prefix and some constants for the event names. It also have a function for triggering and running the callbacks.
jQuery UI (source: https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.widget.js) also have a common function on the widget class for triggering events (usage: https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.dialog.js), but you can see that the events are hard coded on the middle of the source, instead of constants on the top like on Colorbox.
I personally think, and do it in my own plugins, that creating constants is much better if you have a lot of events to trigger, but its not necessary if you will fire only 2 or 3 events.
A helper function is a must have and should be part of your template.
The event names I use and see around all follow the standard CamelCase e.g. beforeClose.
Some advocate the use of a prefix for events like on Colorbox's cbox_open or even click.myPlugin (see: http://api.jquery.com/on/#event-names)
Conclusion: try to follow best practices and conventions for programming in general and watch for the better examples out there.
in plugin create object litereal like
var plugin = {
show:function(){
// code for show()
}
};