React Summit

React Summit 2022

Usually creating web and mobile apps require different tech stacks, and it is pretty hard to share code. This talk will show how I added a React web app and a React Native mobile app in the same monorepo using Nx, and how I optimized codeshare between react web app and react native mobile app. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

How to Share Code between React Web App and React Native Mobile App in Monorepo

# Hello everyone, welcome to my presentation. My topic is how to share code between React Web and React Native mobile apps. First, let me introduce myself. My name is Emily. I am a developer in Toronto and I currently work for a company called Narwhal.io. I like hiking, biking, kayaking and all the outdoor activities. I'm going to run a half marathon in October this year. So I am preparing for that almost every weekend. Also, I used to be a native iOS developer, but that was super, super long ago. Fortunately I turned to be a web developer. This presentation will take you through my journey on how to build both web and a mobile app and utilize code share. A problem I tried to solve is I got this awesome idea. Not only I want to create a web app, but I also want to create a mobile version for the app. However, users expect different experience from web and mobile. Of course, I'm not going to use native iOS and Android approach because that will require too many tech stack. Naturally, I choose React and React Native as my tech stack. However, here are still some challenges presented. React and React Native are still two different tech stacks. The UI code are completely different. React Native uses native components instead of using web components as its building block. However, I still want to achieve feature parity, meaning I want a mobile and a web app to have the same features and share the same business logic. The solution for this is definitely Monorepo. But which one? The solution I came up with, not surprisingly, is NX. What is NX? NX is a powerful Monorepo tool that will set up React and React Native apps for you out of the box. Let's do a quick demo.
First, let's create an NX workspace. In terminal, enter npx create new workspace. For this example, I'm going to name the workspace React Summit. I'll use React as the default plugin and name the app as web. Then after everything got installed, let me go inside this workspace folder and install now React Native package. Then enter a command to generate a React Native app. I'll name this app as mobile. If I open the React Summit workspace folder, under apps, there are currently four folders. It has the web app and the mobile app I just created, and the e2e folders. If I enter NX serve web, it will serve up the default React web app. Meanwhile, to run the mobile app, in terminal, I enter the command NX run iOS. In a different terminal, I enter NX run Android. You will serve up the iOS and Android apps in simulator, respectively. Now let's look at the dependency graph. In terminal, enter NX graph. I should see the dependency graph of this project. Notice there's nothing shared between web and mobile apps. Then let's create a shared library. In terminal, enter the command NX generate live. For this example, I'm going to call this library constants. Under the labs folder, I should now see a constants folder got created. Inside index.ts file, I'm going to create a constant variable called title. Then let me go to the web app folder. First, I'm going to import the title variable from the constant library. After that, I'm going to pass the title constants to the title prop.

If I launch the web app again, I should notice that title got changed. Same goes for the mobile app. I should also be able to import from the shared library and change the title to be from this library. If I open up the dependency graph again, I should see that both mobile and web import from this constants library. Sharing a constant variable does not seem to be that useful. However, imagine what could be shared or the known UI related code could be shared. For example, business logic and state management. These will ensure feature parity that for same features, developers don't need to implement same logic twice. You could exist only once inside a shared library. Essentially, with help from NX, the project setup would look like this. For the apps, you only contain UI code. For the known UI related code, I could create libraries for those. For more information, you could check out my blog post linked on the bottom of the page. The end. Thanks for listening.

Emily Xiong

TestJS Summit

TestJS Summit 2021

For developers, it is better to catch any a11y defects during unit and e2e testings. This talk is going to show how to automate a11y testing using jest and cypress. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

How to Catch a11y Defects During Unit and E2E Testing

Hello everyone, I'm going to show you some ways to catch accessibility defects during unit and end-to-end testing. First, a bit about myself. I'm Emily. I'm a developer in Toronto and I currently work for a company named Narwhal. So this is how fixing accessibility bugs feels like to me. Basically doing a lot of patch fixes. As a developer, accessibility bug is a type of bug I do not wish to be assigned to. In my past projects, accessibility testing is usually done at the very end of a project. By the time I need to fix those bugs, the page is already built. It is very hard to make any structural change and move components around. This talk will show you some ways for developers to automate some accessibility testing while we are doing the development. I'm going to show you how I add accessibility testing to this simple website I've created. It is a search engine for Studio Ghibli. So Studio Ghibli is a Japanese animation company. This simple app would allow you to search any films and characters under this studio. So this is what this website looks like. You can search anything. For example, princess. If I enter princess here and search, it will show me any princess related films. If I search for example Kiki here, it will show me films and characters related to Kiki. I can click the film here and it shows me the film detail. Quickly go through the tech stack. Frontend is React. Monorepo tool is NX, which is built by my company Narwhal. NX is a powerful tool that will set up unit and end-to-end testing for your outdoor box.
So I highly recommend you to check it out. For unit testing, I'm going to use jazz and jazzX. For end-to-end testing, I'm going to use cypress and cypressX.

For unit testing, I use jazz and jazzX. You can install jazzX and type in, use the command here. Now with jazzX installed, I need to set up. I add a setup file named jazz.setup.js here. And inside the jazz config file, I need to add a key setupFileAfterEnvironment and point to jazz.setup.js here. Inside jazz.setup.js, this is what it looks like. It's very simple. You just have an import from jazz.so.x here, and it also extends jazz's expect function to include, to have no violations from jazzX. Now the setup is done. I want to unit test the search form component on the top here. It's a really simple search form. It has a text field and a search submit button. Currently, you have a default test to check whether it renders successfully or not. Now I want to add unit test for the component to check whether it has any accessibility violation. Note, I've imported from jazz.so.x on the top here. Then I add a unit test to check for accessibility violations. It renders the component here. And then you pass the container to the x from jazz.so.x library. You expect the output here to have no violations. The unit test will be very simple. It has two lines here, and it's pretty easy to add. Now when I run a unit testing again, I would notice that the test failed, which is actually great.
It means the tests are actually working. 
It will show the accessibility errors in the console here. 
Developer could add similar tests to each component for the app. 
If all the components are accessible, the entire app are more likely to be accessible. 
It is good that we allow developers to add accessible unit tests while just building the components. 
The components could be standalone and do not even need to be shown up on the browser page. 
This will help to avoid accessibility bug at the component level. 
How about page level? 
I'm going to talk about end-to-end testing. 
It's going to use cypress and cypressX. 
Enter the command to install cypressX. 
I have a cypress test for the search page, which is basically entering text in the search field, submit the search form, and make sure it redirects to the results page with the right query parameter. 
So this is what the cypress test looks like. 
You enter the text field and redirect to the results page. 
To set up cypressX testing, I need to add typing first. 
In the tsconfig file, under compile option types, I need to add cypressX here. 
Also in the support file, I add the import from cypressX. 
Now I'm done with the cypressX testing. 
I'm ready to add cypressX test. 
In the before-each statement, I need a line to inject X here, then I simply add a test. 
I just have one line. 
Check accessibility. 
Now I run the cypress test again. 
Notice it failed. 
I have added a console log to output accessibility violations on the search page here. 
This will help test app on the page level and prevent accessibility-related regression bug.
With all these tools, it will be easier for developers to avoid accessibility bug during development rather than going through them when the entire app is built. This is the end of my presentation. Thanks for listening.

In the next few slides, I will be showing a sample application which uses the accessibility features.

For example, let us see how we can implement the screen readers in this application.

First, we need to set the content description to the text view.

On Android, the content description is the text that is read by the screen reader.

To set the content description, we need to add android:contentDescription attribute to the text view.

Now, when we run the application and access the text view, the text that is read by the screen reader is the one that is set in the content description.

We can also make the text view accessible.

In order to do this, we need to make the text view focusable, so we add android:focusable attribute and set it to true.

Next, we need to add android:focusableInTouchMode attribute and set it to true.

This makes the text view focusable when the app is in touch mode.

Finally, we need to set the click listener to the text view.

Now, when we run the application and try to focus on the text view, we can see that the text view is focused.

We can also see the bounding box around the text view.

When the text view is focused, we can also see that the screen reader reads the text view.

The screen reader read the text that is set in the content description of the text view.

Next, let us see how we can implement a Talk Back feature in this application.

In order to do this, first we need to add the android:importantForAccessibility attribute to the text view.

We can set the android:importantForAccessibility attribute to auto.

This means that the text view is important for accessibility.

Now, when we run the application, we can see that the text view is focused, and we can also see the bounding box around the text view.

The screen reader also reads the text that is set in the content description of the text view.

We can also see that the screen reader reads the text that is set in the content description of the text view even outside the bounding box.

When we press the button, the screen reader reads the text that is set in the button.

The Talk Back feature does this by default.

We can also make the Talk Back feature read the text that is set in the text view, even when the text view is not focused.

In order to do this, we need to set the android:accessibilityLiveRegion attribute to the text view.

We can set the android:accessibilityLiveRegion attribute to assertive.

Now, when we run the application, we can see that the screen reader reads the text that is set in the text view, even when the text view is not focused.

We can also see that the screen reader reads the text that is set in the text view, even when the text view is outside the bounding box.

We can also see that the screen reader reads the text that is set in the text view, even when the button is focused.

In the next few slides, I will be briefly talking about a few tools to test the accessibility of our app.

These tools are useful for developers to avoid accessibility bug during development rather than going through them when the entire app is built.

The first tool that I will be talking about is the Accessibility Scanner.

The accessibility scanner is a free app for Android that helps developers access their apps for common accessibility issues.

The accessibility scanner is available for free on the Google Play Store.

The next tool that I will be talking about is the Accessibility Developer Tools.

The Accessibility Developer Tools is a part of the Chrome DevTools, which is a set of web authoring and debugging tools built into Google Chrome.

The Accessibility Developer Tools allows us to inspect the accessibility properties of the elements in a webpage.

The Accessibility Developer Tools is available in the Chrome DevTools.

The Accessibility Developer Tools is also available as a Chrome Extension.

The next tool that I will be talking about is the Accessibility Insights for Android.

The Accessibility Insights for Android is a free and open source tool for developers to debug and fix accessibility issues in Android apps.

The Accessibility Insights for Android is available for free on the Google Play Store.

The Accessibility Insights for Android is also available on GitHub.

With all these tools, it will be easier for developers to avoid accessibility bug during development rather than going through them when the entire app is built.

This is the end of my presentation. Thanks for listening.