I have a class "MessageDisplay" of which I want to call the function sendMassageToServer from the outside. I´ve built a helper function to call from another file. But how do you export functions that are inside classes?
These data are just examples.
main.js
export function sendSpeechToServer(query){
MessageDisplay.sendMessageToServer(query);
}
class MessageDisplay extends React.Component {
constructor(props) {
super(props);
this.state = {message : []};
}
(export const??) sendMessageToServer(searchQuery) {
...code
}
}
We are accesing the sendSpeechToServer() function from another file. Unortunately I am not even able to reach sendMessageToServer() from inside sendSpeechToServer().
Any help surely is appreciated. :)
EDIT:
The answer is found. For any other people:
export function sendSpeechToServer(query){
let test = new MessageDisplay();
test.sendMessageToServer(query);
}
Better way to separate component(MessageDisplay) and sendMessageToServer.
Then you can import sendMessageToServer awry where. You can inject sendMessageToServer like a props:
// main.js
import { sendMessageToServer } from './api';
<MessageDisplay sendMessage={sendMessageToServer} />
// MessageDisplay.js
import React, { Component } from 'react';
import PropTypes from 'prop-types';
class MessageDisplay extends Component {
static propTypes = {
sendMessage: PropTypes.func.isRequired,
}
handleClick = (e) => {
e.preventDefault();
this.props.sendMessage();
};
render() {
return (<button onClick={this.handleClick}>Send to</button>)
}
}
export default MessageDisplay;
It useful for testing.
Instantiating a component manually for general purposes like let test = new MessageDisplay() is an antipattern, this indicates that a class is misused.
React component classes are primarily intended to make lifecycle hooks available and maintain state. They can sparsely benefit from inheritance (besides the relationship with React.Component) and other OOP traits.
The fact that it's possible to use component method as new MessageDisplay().sendMessageToServer(query) means that it was a mistake to make it component method in the first place. Classes aren't supposed to be glorified namespaces; ES modules play the role of namespaces in modern JavaScript.
A proper way is to extract the method and use it in both places as regular helper function. Functional approach is considered idiomatic in React.
export function sendSpeechToServer(query){
let test = new MessageDisplay();
test.sendMessageToServer(query);
}
it is bad, because you should not, create new react.component instance with new keyword,
better use static function like this
static sendMessageToServer(searchQuery) {
...code
}
and then
export function sendSpeechToServer(query){
MessageDisplay.sendMessageToServer(query);
}
Related
I am trying to shoe horn mobx into a vr application I am making with react 360. I've tried to use the decorator syntax but after wasting a solid chunk of time trying to implement it, I've decided to use the nondecorator syntax. Here is an example that I came across from the mobx documentation that I have a question on. Here is the code:
import {observer} from "mobx-react";
var timerData = observable({
secondsPassed: 0
});
setInterval(() => {
timerData.secondsPassed++;
}, 1000);
#observer class Timer extends React.Component {
render() {
return (<span>Seconds passed: { this.props.timerData.secondsPassed } </span> )
}
};
ReactDOM.render(<Timer timerData={timerData} />, document.body);
Notice the observer declaration on the Timer class. The documentation states this.
Note that using #observer as decorator is optional, observer(class Timer ... { }) achieves exactly the same.
Would this be the correct way of implementing Timer?
observer(class Timer extends React.Component {
render() {
return (<span>Seconds passed: { this.props.timerData.secondsPassed } </span> )
}
})
Concerning the code snippet you have added I don't know whether it is a valid way or not, but here's the way I'm using MobX without the decorator syntax in my application project:
Create your MobX store, say MyStore.js like the following:
import {observable, action, computed, decorate} from 'mobx';
export default class MyStore {
storeMap = observable(new Map());
storeArray = observable([]);
storeBoolean = false
get storeMapSize() {
return this.storeMap.size;
}
setStoreBoolean(value) {
this.storeBoolean = value;
}
}
decorate(MyStore, {
storeMap: observable,
storeArray: observable,
storeBoolean: observable
storeMapSize: computed,
setStoreBoolean: action
});
Then in your component Timer.js:
import {inject, observer} from "mobx-react";
class Timer extends React.Component {
render() {
return (<span>value from store: { this.props.myStore.storeMap.get('any_key') } </span> )
}
}
export default inject('myStore')(observer(Timer));
and you can create as many stores as you want and inject all of them to your components using the same inject method and use them in the same way via this.props, for example
export default inject('myStore', 'anotherStore', 'anotherNewStore')(observer(Timer));
Suppose I had this layout below:
class Navigation extends React.Component {
primaryFun() { console.log('funn') }
secondaryFun() {
this.primaryFun();
}
}
I'd of expected this to then call primary but instead I get an undefined, Ok.
So I thought I'd add a constructor to bind the function to this:
constructor(props) {
super(props)
this.primaryFun = this.primaryFun.bind(this);
}
but primary fun is still undefined.
In my real project I'm calling these on a mouseOut event.
Feels like the above should work and tbh the documentation for React is all over the shot so couldn't find much here.
Are you looking for something like this calling one function inside the other
import React, { Component } from 'react';
import './App.css'
class App extends Component {
constructor(){
super()
this.mouseClick = this.mouseClick.bind(this);
this.primaryFun = this.primaryFun.bind(this);
this.secondaryFun = this.secondaryFun.bind(this);
}
primaryFun(){
console.log('primaryFun funn')
}
secondaryFun(){
console.log('secondaryFun funn')
this.primaryFun()
}
mouseClick(){
this.secondaryFun()
}
render() {
return (
<div onClick={this.mouseClick}>
Hello World!
</div>
);
}
}
export default App;
Here when you click on "Hello world" secondaryFun is called and inside secondaryFun , primaryFun is been triggered
You also need to bind the secondaryFun function to use this inside that. Without that, the this inside the function secondaryFun will refers to the function scope which is secondaryFun
You need to bind this in your mouseOut
onMouseOut={this.secondaryFun.bind(this)}
Or a as best practice use the Lambda syntax. It'll bind this for you
onMouseOut={()=>this.secondaryFun()}
Make sure both functions have the correct this scope. If you are using class properties, see https://babeljs.io/docs/plugins/transform-class-properties/. Which already present on the babel-preset-react-app used by create-react-app, you can use that and write those as arrow functions, as seen on the babel link. And avoid having to use .bind on the constructor.
You must bind() both two functions.
You should that:
class Navigation extends React.Component {
constructor(props) {
super(props)
this.primaryFun = this.primaryFun.bind(this);
this.secondaryFun = this.secondaryFun.bind(this);
}
primaryFun() {
console.log('funn')
}
secondaryFun() {
this.primaryFun();
}
}
Is there a way to define a function to hook before each component in my app is mounted?
The idea is that if a component is blacklisted it doesn't mount at all.
The solution must leave the components unmodified for backward compatibility and should run in production (so rewire and other testing tools are probably off the table but open to suggestions :) )
Example
//something like this...
ReactDOM.beforeEachComponentMount( (component, action) => {
if(isBlacklisted(component)){
action.cancelMountComponent();
}
}
Could you write a simple Babel plugin that transforms blacklisted components to a noop functional component () => {} at compile time?
You could wrap the required components inside a higher order component that checks whether the component is blacklisted or not.
for example :
class YourComponent extends Component {
constructor(props){
super(props);
}
render(){
return(
// your component goes here ..
);
}
}
export default WithPermission(YourComponent);
check if the component needs to be rendered or not inside the HOC WithPermission.
function withPermission(YourComponent) {
class WithPermission extends React.Component {
constructor(props) {
super(props);
}
// you can check the props inside ComponentDidMount and set a flag if
// the component satisfies the criteria for rendering.
render() {
const {blacklistedComponents,...rest} = this.props;
if(!blackListedComponents){
return <YourComponent {...rest} />
}
else{
return null;
}
}
}
}
There is no such functionality out of box.
You may shim React rendering cycle, I mean shim React.createElement method and validate component before it is added to VDOM
All JSX is processed through React.createElement
e.g. at the start of app add
let React = require('react');
let originalCreateElement = React.createElement;
React.createElement = function() {
let componentConstructorOrStringTagName = arguments[0];
if (isBlacklisted(componentConstructorOrStringTagName)) {
return null;
}
return originalCreateElement.apply(this, arguments);
}
The best idea I can think of is to "shim" react and Component
if you are using webpack you can use this:
https://webpack.js.org/guides/shimming/
in the bottom line that means instead of importing react you will import your own class of react.
In your new class you could extend React Component and place a check on the render function or something similar.
You could implement a custom ESLint rule and catch this as soon as a dev tries to use a blacklisted components. The id-blacklist rule is similar to what you want, but at the identifier level. The source code looks simple. Maybe you can adapt it to disallow more then just identifiers.
Consider the following solution:
Let there be a file where you declare which components are blacklisted:
let blacklist = [{
name: 'secretComponent',
invoke: (props)=> {
return <SecretComponent ...props />
},
isBlacklisted: true
},{
name: 'home',
invoke: (props)=> {
return <HomeComponent ...props />
},
isBlacklisted: false
},{
name: 'login',
invoke: (props)=> {
return <LoginComponent ...props />
},
isBlacklisted: false
}];
Define a Higher Order Component like below:
function renderIfNotBlacklisted(name) {
let component = blacklist.map(x=> x.name == name); //blacklist from above
if (!component.isBlacklisted){
return component.invoke();
} //else can be handled as you will
//You can keep a default component to render or send empty values
}
Call this component in the render function wherever you want this feature to work. This way you have a centralized location to managed blacklisted components (blacklist.json can be in the root of react project or fetched from API on first run)
I have struggled a lot trying to figure out how to combine ReactJS and firebase (3).
Luckily I found the awesome re-base repo, which is awesome and exactly what I want.
fb-config.js
var Rebase = require('re-base');
var base = Rebase.createClass({
apiKey: "apiKey",
authDomain: "projectId.firebaseapp.com",
databaseURL: "https://databaseName.firebaseio.com",
storageBucket: "bucket.appspot.com",
messagingSenderId: "xxxxxxxxxxxxxx"
});
export default base;
app.js
import React, { Component } from 'react';
import base from 'fb-config';
import ExampleComponent from './components/ExampleComponent';
class App extends Component {
constructor() {
super();
// getInitialState
this.state = {
DB: {}
};
}
componentDidMount() {
this.ref = base.syncState('demo',
{ context: this,
state: 'DB' }
);
}
componentWillUnmount() {
base.removeBinding(this.ref);
}
render() {
return (
<ExampleComponent />
)
}
}
export default App
components/ExampleComponent.js
import React, { Component } from 'react';
import base from '../fb-config';
class ExampleComponent extends Component {
constructor(props, context){
super(props, context);
this.pushing = this.pushing.bind(this);
}
pushing() {
const now = new Date().getTime();
let data = {};
data[now.toString(16)] = 'Hello World';
base.fetch('demo', {
context: this,
asArray: false
}).then( snapshot => {
data = {... snapshot, ...data};
base.post('demo', {data})
.then( () = { console.log("pushed") });
});
}
render() {
return (
<button onClick={this.pushing}>PUSH</button>
)
}
};
export default ExampleComponent;
This setup works. But I would like to move the pushing method to another file (like fb-commands.js). How would I do that?
You can move pushing as-is, all you need is to pass context to the function, since it wont have access to the component instance via this.
// fb-commands.js
export const pushing = (context) => {
const now = new Date().getTime();
let data = {};
data[now.toString(16)] = 'Hello World';
base.fetch('demo', {
context: context,
asArray: false
}).then( snapshot => {
data = {... snapshot, ...data};
base.post('demo', {data})
.then(() => console.log("pushed"));
});
};
// components/ExampleComponent.js
import React, { Component } from 'react';
import base from '../fb-config';
import {pushing} from 'path/to/fb-commands';
class ExampleComponent extends Component {
render() {
return (
<button onClick={() => pushing(this)}>PUSH</button>
);
}
}
export default ExampleComponent;
Based on my experience, I can think of 3 approaches (maybe there are more).
Approach #1: Via ES6 Import / Export (Simple)
ArneHugo describes it well in his answer.
Just export pushing function to a module and then import it and use it directly. Pass the this context or any other params needed.
Sounds awesome to me if you want to share utility functions.
Approach #2: Via Mixins.
That's not a good practice.
Plus, mixins are not supported when using React components written in ES6 syntax. Moreover, they will not have support for ES6 classes in React. The reason is that they are considered harmful.
So, mixins are on their way out.
Approach #3: Via Composition (Advanced)
That is the best option if you need to implement something more advanced then just re-using common methods. Let's say if you want:
to reuse logic and bootstrap abstraction
to render Highjacking
to do State abstraction and manipulation
to do Props manipulation
Then, enter Composition and Higher-Order Components!
A higher-order component is just a function that takes an existing component and returns another component that wraps it.
You can use this approach to wrap the component and not only share common code / logic, but share data, manipulate state, props and etc.
More on this topic you can read on the franleplant's great post here.
Conclusion
If you need just a helper method abstraction - use Approach #1.
Never use Approach #2.
If you want something more then that - consider applying Approach #3.
I am following this tutorial: http://reactkungfu.com/2015/07/approaches-to-testing-react-components-an-overview/
Trying to learn how "shallow rendering" works.
I have a higher order component:
import React from 'react';
function withMUI(ComposedComponent) {
return class withMUI {
render() {
return <ComposedComponent {...this.props}/>;
}
};
}
and a component:
#withMUI
class PlayerProfile extends React.Component {
render() {
const { name, avatar } = this.props;
return (
<div className="player-profile">
<div className='profile-name'>{name}</div>
<div>
<Avatar src={avatar}/>
</div>
</div>
);
}
}
and a test:
describe('PlayerProfile component - testing with shallow rendering', () => {
beforeEach(function() {
let {TestUtils} = React.addons;
this.TestUtils = TestUtils;
this.renderer = TestUtils.createRenderer();
this.renderer.render(<PlayerProfile name='user'
avatar='avatar'/>);
});
it('renders an Avatar', function() {
let result = this.renderer.getRenderOutput();
console.log(result);
expect(result.type).to.equal(PlayerProfile);
});
});
The result variable holds this.renderer.getRenderOutput()
In the tutorial the result.type is tested like:
expect(result.type).toEqual('div');
in my case, if I log the result it is:
LOG: Object{type: function PlayerProfile() {..}, .. }
so I changed my test like:
expect(result.type).toEqual(PlayerProfile)
now it gives me this error:
Assertion Error: expected [Function: PlayerProfile] to equal [Function: withMUI]
So PlayerProfile's type is the higher order function withMUI.
PlayerProfile decorated with withMUI, using shallow rendering, only the PlayerProfile component is rendered and not it's children. So shallow rendering wouldn't work with decorated components I assume.
My question is:
Why in the tutorial result.type is expected to be a div, but in my case isn't.
How can I test a React component decorated with higher order component using shallow rendering?
You can't. First let's slightly desugar the decorator:
let PlayerProfile = withMUI(
class PlayerProfile extends React.Component {
// ...
}
);
withMUI returns a different class, so the PlayerProfile class only exists in withMUI's closure.
This is here's a simplified version:
var withMUI = function(arg){ return null };
var PlayerProfile = withMUI({functionIWantToTest: ...});
You pass the value to the function, it doesn't give it back, you don't have the value.
The solution? Hold a reference to it.
// no decorator here
class PlayerProfile extends React.Component {
// ...
}
Then we can export both the wrapped and unwrapped versions of the component:
// this must be after the class is declared, unfortunately
export default withMUI(PlayerProfile);
export let undecorated = PlayerProfile;
The normal code using this component doesn't change, but your tests will use this:
import {undecorated as PlayerProfile} from '../src/PlayerProfile';
The alternative is to mock the withMUI function to be (x) => x (the identity function). This may cause weird side effects and needs to be done from the testing side, so your tests and source could fall out of sync as decorators are added.
Not using decorators seems like the safe option here.
Use Enzyme to test higher order / decorators with Shallow
with a method called dive()
Follow this link, to see how dive works
https://github.com/airbnb/enzyme/blob/master/docs/api/ShallowWrapper/dive.md
So you can shallow the component with higher order and then dive inside.
In the above example :
const wrapper=shallow(<PlayerProfile name={name} avatar={}/>)
expect(wrapper.find("PlayerProfile").dive().find(".player-profile").length).toBe(1)
Similarly you can access the properties and test it.
You can use 'babel-plugin-remove-decorators' plugin. This solution will let you write your components normally without exporting decorated and un-decorated components.
Install the plugin first, then create a file with the following content, let us call it 'babelTestingHook.js'
require('babel/register')({
'stage': 2,
'optional': [
'es7.classProperties',
'es7.decorators',
// or Whatever configs you have
.....
],
'plugins': ['babel-plugin-remove-decorators:before']
});
and running your tests like below will ignore the decorators and you will be able to test the components normally
mocha ./tests/**/*.spec.js --require ./babelTestingHook.js --recursive
I think the above example is confusing because the decorator concept is used interchangeably with idea of a "higher order component". I generally use them in combination which will make testing/rewire/mocking easier.
I would use decorator to:
Provide props to a child component, generally to bind/listen to a flux store
Where as I would use a higher order component
to bind context in a more declarative way
The problem with rewiring is I don't think you can rewire anything that is applied outside of the exported function/class, which is the case for a decorator.
If you wanted to use a combo of decorators and higher order components you could do something like the following:
//withMui-decorator.jsx
function withMUI(ComposedComponent) {
return class withMUI extends Component {
constructor(props) {
super(props);
this.state = {
store1: ///bind here based on some getter
};
}
render() {
return <ComposedComponent {...this.props} {...this.state} {...this.context} />;
}
};
}
//higher-order.jsx
export default function(ChildComp) {
#withMui //provide store bindings
return class HOC extends Component {
static childContextTypes = {
getAvatar: PropTypes.func
};
getChildContext() {
let {store1} = this.props;
return {
getAvatar: (id) => ({ avatar: store1[id] });
};
}
}
}
//child.js
export default Child extends Component {
static contextTypes = {
getAvatar: PropTypes.func.isRequired
};
handleClick(id, e) {
let {getAvatar} = this.context;
getAvatar(`user_${id}`);
}
render() {
let buttons = [1,2,3].map((id) => {
return <button type="text" onClick={this.handleClick.bind(this, id)}>Click Me</button>
});
return <div>{buttons}</div>;
}
}
//index.jsx
import HOC from './higher-order';
import Child from './child';
let MyComponent = HOC(Child);
React.render(<MyComponent {...anyProps} />, document.body);
Then when you want to test you can easily "rewire" your stores supplied from the decorator because the decorator is inside of the exported higher order component;
//spec.js
import HOC from 'higher-order-component';
import Child from 'child';
describe('rewire the state', () => {
let mockedMuiDecorator = function withMUI(ComposedComponent) {
return class withMUI extends Component {
constructor(props) {
super(props);
this.state = {
store1: ///mock that state here to be passed as props
};
}
render() {
//....
}
}
}
HOC.__Rewire__('withMui', mockedMuiDecorator);
let MyComponent = HOC(Child);
let child = TestUtils.renderIntoDocument(
<MyComponent {...mockedProps} />
);
let childElem = React.findDOMNode(child);
let buttons = childElem.querySelectorAll('button');
it('Should render 3 buttons', () => {
expect(buttons.length).to.equal(3);
});
});
I'm pretty sure this doesn't really answer your original question but I think you are having problems reconciling when to use decorators vs.higher order components.
some good resources are here:
http://jaysoo.ca/2015/06/09/react-contexts-and-dependency-injection/
https://medium.com/#dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750
https://github.com/badsyntax/react-seed/blob/master/app/components/Menu/tests/Menu-test.jsx
https://github.com/Yomguithereal/baobab-react/blob/master/test/suites/higher-order.jsx
In my case decorators are very useful and I dont want to get rid of them (or return wrapped and unwrapped versions) im my application.
The best way to do this in my opinion is to use the babel-plugin-remove-decorators (which can be used to remove them in tests) has Qusai says, but I wrote the pre-processor differently like below:
'use strict';
var babel = require('babel-core');
module.exports = {
process: function(src, filename) {
// Ignore files other than .js, .es, .jsx or .es6
if (!babel.canCompile(filename)) {
return '';
}
if (filename.indexOf('node_modules') === -1) {
return babel.transform(src, {
filename: filename,
plugins: ['babel-plugin-remove-decorators:before']
}).code;
}
return src;
}
};
Take notice of the babel.transform call that im passing the babel-plugin-remove-decorators:before element as an array value, see: https://babeljs.io/docs/usage/options/
To hook this up with Jest (which is what I used), you can do it with settings like below in your package.json:
"jest": {
"rootDir": "./src",
"scriptPreprocessor": "../preprocessor.js",
"unmockedModulePathPatterns": [
"fbjs",
"react"
]
},
Where preprocessor.js is the name of the preprocessor.