Free Resources
Intro to NativeScript
Recommended Articles
Introducing the new Expo, Styled Components, and Zustand Starter Kit
Intro We are delighted to announce our brand new Expo React Native starter kit to our Starter.dev kits collection. We built this starter kit to enable our team members who work mostly with web technologies to make an easy transition for them to work on native mobile apps with their current knowledge without any extra effort. This Starter kit contains: - Expo a React native wrapper. - Styled Components lets you write actual CSS in your JavaScript-like web. - Zustand A small, fast, and scalable barebones state-management solution. - TypeScript JavaScript with syntax for types. - Jest is a delightful JavaScript Testing Framework with a focus on simplicity. - React Navigation Routing and navigation for Expo and React Native apps. Problems This Kit Addresses React Native Styling One of the most difficult things for React Native beginners is its styling system. It's difficult for people who come from a web background because it’s not similar to CSS at all. It has different units, and each property accepts a different value. For more information visit React Native Style Documentation styled-components/native fixed that problem, you literally write CSS like for web and it translates the CSS code to a React Native Styles without any extra effort. Share Components Across Platforms Thanks to the Expo team, we can use the React Native components cross-platform, even with frameworks like Next.js. This saves teams a lot of work. Instead of building the same feature twice, one for the web and the other for the mobile apps, we only build it once. Let me show you an example: A lot of libraries in the React ecosystem use the setImmediate() API (like react-native-reanimated). It’s a method used to break up long-running operations, and run a callback function immediately after the browser has completed other operations such as events and display updates, which Next.js doesn't polyfill by default. To fix this, you can polyfill it yourself. First, we need to install set immediate package yarn add setimmediate Then import it in the app root pages/_app.js import 'setimmediate'; Use the @expo/next-adapter in the next.config.js ` Add image support with next-images ` Add font support with next-fonts ` Now you can use your Expo React Native components in Next.js site. Skip the Tedious Steps of Installing React Navigation We use React Navigation in almost every project we work on, it’s a necessary piece of the app, so we already set it up so you can start your new app quickly. We also grouped the screens under the src/screens directory, where each screen has its own folder with its related files. Defining a better organization pattern for components to scale your app We structured this project from our experiences with big React projects. One challenging part of using React is that it gives the developer a lot of freedom to choose their own file structure. However this is not good on a bigger app scale, because every developer has their own way to organize the files, and with a big React project that a lot of developers are working on, we usually end up with a mess. We figured this structure out from the previous projects we built. Imagine we have a component, and this component has different files like, testing, …etc Our way to structure the components is: Each component has its own folder: ` Each folder has the component files ` The problem now is the importing sentences gonna be ugly like this: ` So it solve this, we add in each Component folder an index.ts file with the following: ` Now the folder structure will look like this: ` Now the import sentence will be much cleaner: ` This can help keep your files and folders organized, and help scale your codebase with time. Conclusion This starter kit is the result of a lot of experience we gained on React projects we built internally and for clients. It helps you to start quickly without going through the tedious task of installing and setting up dev tools, and at the same time, it helps your app scale more easily....
Apr 26, 2023
4 mins
A Look at Playwright Parallelism
A Look at Playwright Parallelism Playwright is an open-source automation library developed by Microsoft, designed for testing web applications across multiple browsers. It enables developers and testers to write scripts that simulate real user actions when interacting with web pages. Playwright supports major browsers like Chrome, Firefox, and Safari, including their headless modes. Recently, it has gained a lot of popularity for its robustness, ease of use, and cross-browser compatibility. In this blog post, we will take a look at one very useful aspect of Playwright: running tests in parallel. Parallelism in Playwright Parallelism in Playwright refers to running multiple test spec files or even test cases within a spec file simultaneously, greatly improving test execution speed. This is achieved by running the tests in worker processes, where each worker process is an OS process, running independently, orchestrated by the test runner. All workers have identical environments, and each starts its own browser instance. Parallel execution is particularly beneficial in continuous integration and continuous deployment (CI/CD) pipelines, reducing overall build and testing times. Playwright's architecture inherently supports parallelism, and most modern test runners integrating with Playwright can leverage this feature. The parallel execution feature makes Playwright a highly efficient tool for large-scale web application testing. Enabling Parallelism By default, if you scaffold the project using npm init playwright@latest, parallelism is already enabled. Assuming that Playwright's configuration includes three browsers and there is a single spec file with two test cases, the total number of tests that Playwright needs to execute is 3x2 = 6. ` Playwright will decide on how many workers to use based on several factors: - Hardware support: Depending on the number of CPU cores and other system resources, the operating system will decide how many processes Playwright can spin up. - The workers property in the playwright.config.ts file. - The --workers argument to the playwright test command. For example, npx playwright test --workers 4. The --workers argument overrides the workers property in the configuration. However, in both cases, the number of workers can go up to the number of processes that Playwright can spin up, as decided by the operating system. Once it has determined the number of workers, and if the number of workers is larger than 1, Playwright will then decide how to split the work between workers. This decision also depends on several factors, such as the number of browsers involved and the granularity of the parallelism, which can be controlled in several ways: - In the test spec file, you can specify whether to run the test cases in parallel. To run tests in parallel, you can invoke test.describe.configure({ mode: 'parallel' }); before your test cases. - Alternatively, you can configure it per project by setting the fullyParallel: true property. - And finally, you can set it globally in the config, using the same property: fullyParallel: true. Therefore, if there is more than one worker and the parallel mode is enabled, Playwright will assign test cases to each worker as they become available. This scenario is ideal because it means that each test is stateless, and the resources are used most efficiently. ` Disabling Parallelism What if, however, the tests are not stateless? Imagine one test changes the global configuration of the app via some sort of administration page, and the configuration affects different parts of the app, like enabling or disabling features. Other tests, which may be testing those features, would be impacted and would report incorrect results. In such cases, you might want to disable parallelism. You can disable any parallelism globally by allowing just a single worker at any time. Following the instructions from the previous sections to configure the number of workers, you can either set the workers: 1 option in the configuration file or pass --workers=1 to the command line. ` Let's have a look at our test output in this case: ` Now, compare the time it took with one worker versus the time it took with four workers. It took 8.2 seconds with one worker compared to only 3.9 seconds with multiple workers. That might be an inefficient usage of resources, of course, especially if you have a large test suite and some of the tests are stateless and can be run without impacting other tests. Tweaking Parallelism If you want some tests not to run in parallel, but still want to utilize your workers, you can do that. Again, following the configuration options from the previous sections, you can annotate the entire spec file with test.describe.configure({ mode: 'serial' }); to have the tests run sequentially in that spec file, or use the fullyParallel: false property to run tests sequentially on the project level, or using the same property to run tests sequentially on the global level. This means you can still split the tests between workers, but the tests would be run sequentially within a worker depending on the configuration. For example, let's set the number of workers to 4, but set fullyParallel: false globally. ` The tests need to be run sequentially, but since each browser instance effectively provides an isolated environment, this means tests cannot impact each other between environments, and they are safe to be executed sequentially within an environment. This means setting fullyParallel: false on the global level is not the same as having workers: 1, since the browsers themselves offer an isolated environment for the tests to run sequentially. However, since we only have 3 environments (3 browsers), we cannot fully utilize 4 workers as we wanted, so the number of workers is 3. Conclusion In conclusion, Playwright's workers are the core of its parallelism capabilities, enabling tests to run concurrently across different environments and browsers with efficiency. Through its many configuration properties, Playwright allows you to configure parallelism at multiple levels, offering a granular approach to optimizing your test runs. Beyond just executing tests in parallel on a single machine, Playwright's parallelism can even extend to splitting work across multiple machines through sharding, significantly enhancing the scalability of your testing. We hope this blog post was useful. For those interested in delving deeper into the world of Playwright and its powerful features, we've also recently released a JS Drop titled Awesome Web Testing with Playwright, and we also hosted Debbie O'Brien from Microsoft in a Modern Web episode....
Mar 20, 2024
5 mins