Cause 🧐

The beginning of the beginning, simple and crude. In the wechat applet, a line wx.getUserInfo will pop up the user’s authorization to log in. Most applets are easy to use, directly when opening the applets on this method. So at that time, one impression is to open a small program, just pop up window let me log in, want to take my wechat information, give a person a feeling of insecurity.

The code looked like this:

<script>
wx.getUserInfo({
  success(res) {
    // res.userinfo User information}})</script>
Copy the code

If you want to combine it with a business, it usually looks like this (the following code examples all use the WEpy framework) :

<template>
  <! User login is required for this operation.
  <view @tap="clickA">Login operation A is required</view>
  <view @tap="clickB">Need to log in operation B</view>
</template>
<script>
{
  methods = {
    clickA () {
      await getUserInfo() // wx.getUserInfo is wrapped in this
      // Write the business logic of A
    }
    clickB () {
      await getUserInfo()
      // Write the business logic of B}}}</script>
Copy the code

Variable 😩

To prevent abuse, wechat later decided to adjust the interaction and change the authorized login process. An announcement was made, out of the blue, to call wx.getUserInfo and stop popup asking if the user is authorized. Instead, you need to use a native Button component that the user actually clicks on the screen to trigger.

The code now looks like this:

<template>
  <button open-type="getUserInfo" bindgetuserinfo="bindGetUserInfo">Click Authorize login</button>
</template>
<script>
  {
    methods = {
      bindGetUserInfo (e) {
        // e.dail. userInfo User information}}}</script>
Copy the code

It didn’t look like a problem, but it exploded in place. Now there is a lot of redundant code when combined with business:

<template>
  <view>
    <button class="auth-btn" open-type="getUserInfo" bindgetuserinfo="clickA"></button>Login operation A is required</view>
  <view>
    <button class="auth-btn" open-type="getUserInfo" bindgetuserinfo="clickB"></button>Need to log in operation B</view>
</template>
<script>
  {
    methods = {
      clickA (e) {
        if (e.detail.errMsg === 'getUserInfo:ok') {
          // Write the business logic of A
        }
      }
      clickB (e) {
        if (e.detail.errMsg === 'getUserInfo:ok') {
          // Write the business logic of B}}}}</script>
<style lang="less">. Auth-btn {// make its cover transparent on the parent container}</style>
Copy the code

I worked on a legacy project that was so dense with this code that I vomited 3 times 🤮 in 5 minutes. DRY! DRY! DRY! I can’t stand the fact that code cleanliness is aggravating ocD.

Way home 😎

As a pursuit of the wind young, think for a long time, have to think of a rut 🤔, or the development career is full of afflictions. Wepy is a componentized applets framework that allows you to write custom components of applets in the same way you write vUE components. So there was a natural idea. Encapsulate the login button to make it convenient enough.

Finally, the componentized code looks like 🚀 :

<template>
  <view>
    <LoginButton1 @tap.user="clickA"></LoginButton1>Login operation A is required</view>
  <view>
    <LoginButton2 @tap.user="clickB"></LoginButton2>Need to log in operation B</view>
</template>
<script>
  import LoginButton from '@/components/LoginButton'
  {
    components = {
      LoginButton1: LoginButton,
      LoginButton2: LoginButton,
    }
    methods = {
      clickA () {
        // Write the business logic of A directly
      }
      clickB () {
        // write the business logic of B directly}}</script>
Copy the code

{LoginButton1: LoginButton, LoginButton2: LoginButton}} The main reason for this is that wepy components are static components (in other words, compile-time code copy), causing each instantiation to be assigned an id😐. We are looking forward to the upcoming 2.0 release of Wepy that will address this issue.

This may not be optimal, but it is much more convenient.