React Native offers a cross-platform solution, but it doesn’t compromise too much on performance and development efficiency, especially for developers with basic JS and CSS skills. However, JSX syntax takes some time to get used to. As for DOM structure and style and JS processing, it’s a matter of opinion. But it’s also a good way to force you to decouple modules. Because the React component’s data flow is one-way, it introduces a very troublesome problem. It is difficult for components to communicate efficiently. Especially, the communication between two sibling nodes at a deep level becomes extremely complicated, causing transmission pollution to all upstream parent nodes and high maintenance costs. For this, Poplar introduces the Redux architecture to centrally manage application states.

The APP is made up of five basic pages, including the Feed flow homepage (MainPage), the ExplorePage (ExplorePage), my account details page (MinePage), the status created from send page (NewFeed), and the LoginRegPage (LoginRegPage). The page in turn consists of basic components, such as Feed lists, Feed details, comments, tags, photo albums, and so on. If you interact with the server, it’s all handled by the API layer.

At the bottom of the page, TabNavigator consists of five TabNavigator. items, respectively corresponding to the basic page. If the user does not log in, the login registration page will be called when clicking the main page or adding a Tab.

If the user does not log in, the login/registration page will pop up if the user clicks the Feed flow page. After the login or registration is successful, the page will be recalled and the information flow content will be refreshed. The App component in the figure below is the common parent of the sibling nodes of the login page and the home page of the information flow.

This requirement may seem simple, but without Redux, it would be clunky to implement in React and would make a lot of unnecessary code calls redundant.

Let’s first look at how this business process is implemented without Redux.

When clicking the first Item of Tabbar, namely the information flow TAB, check whether the user is logged in or not. This check can be verified by checking whether the application stores tokens locally or by other means of verification. If the user is not logged in, it is necessary to actively update the state state of App components. At the same time, pass the status modification to LoginPage as props, and LoginPage updates its own state:{visible:true} after the new props is passed. If the customer enters the login information and the login succeeds, You need to set the state of the LoginPage to {visible:false} to hide yourself and call the callback that the App passes to tell the parent attachment that the user has logged in successfully. The LoginPage notifies the App component that the App should be logged in, but it hasn’t refreshed the user’s Feed stream yet. Because the MainPage does not know that the user has logged in, the parent component of App needs to tell it that it has logged in and please refresh. How can it be notified? React is a one-way data flow. In order to make the underlying components update, they can only pass the props property, so there is another overhead of the props property. MainPage updates the associated state and updates the Feed stream itself, which finally complete the display of MainPage information after a login. As can be seen from the above analysis, Poplar has a lot of redundant but unavoidable parameter passing when it transitions from unlogged to logged. Because sibling nodes LoginPage and MainPage cannot simply communicate with each other to inform each other of their status, it needs the bridge of App parent to pass messages up and down first.

Let’s take a look at how the same process is done with Redux:

Poplar already has an initial global login status {status: ‘NOT_LOGGED_IN’} for the application due to the introduction of Redux. This status is updated to {status: ‘LOGGED_IN’}, while LoginPage is bound to this state, Redux will immediately notify the component to update its state to {visible:false}. At the same time, the App is bound to the global state managed by Redux, so it can also get {status: ‘LOGGED_IN’}, so it is easy to hide the LoginPage and display the MainPage after the client has logged in. It is very simple and magic, completely does not rely on the layer of parameter pass, component wants to obtain the global state is associated with it, Redux will notify you first.

In App component, UI component is generated into Redux container component through connect method, which can be understood as building a bridge of communication between UI component and Redux and associating store with component.

import {showLoginPage, isLogin} from './actions/loginAction'; import {showNewFeedPage} from './actions/NewFeedAction'; Export default connect((state) => ({status: state.islogin. status, // Login status loginPageVisible: state.showLoginPage.loginPageVisible }), (dispatch) => ({ isLogin: () => dispatch(isLogin()), showLoginPage: () => dispatch(showLoginPage()), showNewFeedPage: () => dispatch(showNewFeedPage()), }))(App)Copy the code

The first argument to the connect method is the mapStateToProps function, which creates a mapping between the data in the store and the PROPS object of the UI component. The mapStateToProps method is called whenever the Store is updated. Is a mapping of UI component props to store data. In the code above, the mapStateToProps accepts state as an argument and returns a mapping between the login state of a UI component and the login state of state in the Store and whether a login page is displayed. The App component state is then associated with Redux’s Store.

The second parameter, mapDispatchToProps, allows action to be bound to a component as props, returning a mapping between the UI component props and the Redux Action. The isLogin showLoginPage showNewFeedPageprops of the App component in the code above maps to the Action of Redux. Call isLogin actually calls store.dispatch(isLogin) action in Redux. Dispatch distributes the action to reducer.

Now that components are associated with the Redux global state, how do you implement the flow of state? How does login status spread across the entire application?

The Actions and Reducer in Redux are required. The actions receive events from the UI components, and the Reducer responds to the actions, returns a new store, and triggers updates of UI components associated with the store.

export default connect((state) => ({
  loginPageVisible: state.showLoginPage.loginPageVisible,
}), (dispatch) => ({
  isLogin: () => dispatch(isLogin()),
  showLoginPage: (flag) => dispatch(showLoginPage(flag)),
  showRegPage: (flag) => dispatch(showRegPage(flag)),
}))(LoginPage)

this.props.showLoginPage(false);
this.props.isLogin();Copy the code

In this login scenario, LoginPage binds its props to store and action, and if the login succeeds, calls showLoginPage(false) Action to hide itself. Reducer received the action from this dispatch and updated the store state:

//Action export function showLoginPage(flag=true) { if(flag == true) { return { type: 'LOGIN_PAGE_VISIBLE' } } else { return { type: 'LOGIN_PAGE_INVISIBLE' } } } //Reducer export function showLoginPage(state=pageState, action) { switch (action.type) { case 'LOGIN_PAGE_VISIBLE': return { ... state, loginPageVisible: true, } break; case 'LOGIN_PAGE_INVISIBLE': return { ... state, loginPageVisible: false, } break; default: return state; }}Copy the code

Also call the isLogin action to update the global status of the application to logged in:

//Action
export function isLogin() {
  return dispatch => {
      Secret.isLogin((result, token) => {
        if(result) {
          dispatch({
            type: 'LOGGED_IN',
          });
        } else {
          dispatch({
            type: 'NOT_LOGGED_IN',
          });
        }
      });
  }
}

//Reducer
export function isLogin(state=loginStatus, action) {
    switch (action.type) {
      case 'LOGGED_IN':
        return {
          ...state,
          status: 'LOGGED_IN',
        }
        break;
      case 'NOT_LOGGED_IN':
        return {
          ...state,
          status: 'NOT_LOGGED_IN',
        }
        break;
      default:
        return state;
    }
}Copy the code

Because the App component has been associated with this global login state, after reducer updated this state, the App will also receive this update and re-render itself, at this point MainPage will be rendered:

const {status} = this.props; return ( <TabNavigator> <TabNavigator.Item selected={this.state.selectedTab === 'mainTab'} renderIcon={() => <Image style={styles.icon} source={require('./imgs/icons/home.png')} />} renderSelectedIcon={() => <Image style={styles.icon} source={require('./imgs/icons/home_selected.png')} />} onPress={() => { this.setState({ selectedTab: 'mainTab' }); if(status == 'NOT_LOGGED_IN') { showLoginPage(); }} > // Global status changed from NOT_LOGGED_IN to LOGGED_IN {status == 'NOT_LOGGED_IN'? <LoginPage {... this.props}/>:<MainPage {... this.props}/>}Copy the code

Poplar, as an overall Maven project, has no business functionality or code at the top level, and a dual identity for the poM dependency import at the bottom level that provides the basis for poplar-API: Poplar-user-service: a microservice provider that provides registration, login, and user management services Poplar notice-service: a microservice provider that provides notification messaging services

Each subproject is created separately as a Module

The service providers and consumers described above rely on Dubbo for remote invocation, but they also need a registry to register service providers and notify service consumers. Zookeeper is one such registry implementation, and Poplar uses Zookeeper as its registry.

Dubbo administrative console installation

git clone https://github.com/apache/incubator-dubbo-ops
cd incubator-dubbo-ops && mvn package  Copy the code

Decompress the war package to the Tomcat webapps/ROOT directory (the ROOT directory should be emptied in advance). You can view the dubo. properties file that contains the IP address and port of the registry Zookeeper

Dubbo. Registry. Address = zookeeper: / / 127.0.0.1:2181 dubbo. Admin. Root. The password = root dubbo. Admin. Guest. Password = guestCopy the code

Start tomcat

./bin/startup.sh 	Copy the code

access

http://127.0.0.1:8080/   Copy the code

This completes Dubbo’s monitoring setup for the registry

Popular-common, as a common module, defines interfaces and models that both consumers and providers rely on, so that microservices can be accessed to define user service interfaces when they are released

public interface UserService {
    String register(String username, String email, String password);
}Copy the code

As mentioned earlier, Poplar-API acts as an API gateway while also serving as a service consumer, organizing providers to invoke relationships and complete request links.

The API layer uses the @Reference annotation to request services from the registry and communicates with the service provider’s RPC through the UserService interface defined in the Popular-Common module

@RestController @RequestMapping("/user") public class UserController { @Reference private UserService userService; @ResponseBody @RequestMapping("/register") public Message register(String username, String email, String password) { Message message = new Message(); String errno = userService.register(username, email, password); message.setErrno(errno); return message; }}Copy the code

Application. The properties configuration

dubbo.scan.basePackages = com.lvwangbeta.poplar.api.controller dubbo.application.id=poplar-api Dubbo. Application. Name = poplar - API dubbo. Registry. Address = zookeeper: / / 127.0.0.1:2181Copy the code

Poplar uses a separate docker-based deployment model for microservices with databases and registries. Poplar dubbo-Admin is the Dubbo administrative console. Poplar-api poplar-tag-service poplar-action-service poplar-feed-service poplar-user-service is a specific service layer module. Poplar-redis Poplar-mysql provides cache and persistent data support. Poplar-zookeeper is the ZooKeeper registry

poplar-dubbo-admin
poplar-api
poplar-tag-service
poplar-action-service
poplar-feed-service
poplar-user-service
poplar-redis
poplar-mysql
poplar-zookeeperCopy the code

poplar-api poplar-tag-service poplar-action-service poplar-feed-service In the configuration file, you can specify the working directory, basic image, and other information to omit the Dockerfile:

At this point, the back end of the Poplar project is fully built and launched to provide services externally, and clients (whether Web or App) see only one unified API.