Debugging the safari and webview content we use in the application on the device via the computer.
In projects where webview is used, we can resolve errors on the web page by debugging pages and JavaScripts. To do this, you need to connect the device to your computer and use your browser’s developer settings.
In iOS webview, console.log() messages from the web page cannot be displayed in Xcode logs. For this reason, we can easily track logs and perform debugging by using Safari’s developer settings.
Considering these limitations, here are the steps for remote debugging of a web view in iOS:
2. Next, you must also enable developer tools in Safari on your development computer. Launch Safari on your development computer and go to Safari > Preferences in the menu bar. In the preferences pane that appears, click on the Advanced tab, and then enable the Show Develop menu option at the bottom. After doing this, you can close the preferences pane.
3. Connect your iOS device to your development computer and launch your application or safari.
4. In Safari on your development computer, click Develop in the menu bar and select your iOS device name to display a list of webview instances running on your iOS device.
5. Click the dropdown option for the web view you want to debug. This will open a new Safari Web Inspector window to inspect the web view.
Author: Atakan Cengiz Kurt
In this article, which is my first post, I wanted to discuss React’s memoization hooks: useMemo and useCallback. I will explain these hooks, which cause confusion for many people regarding where and how they should be used, along with examples.
If you are working on medium or large scale React projects, you have likely encountered these hooks. You might have even used them just because they were already being used in the project without knowing their exact functions; however, I must say that most of these usages are unnecessary and cause memory leaks. Without further ado, let’s talk about useMemo, useCallback, and their actual intended purposes.
Memory Leak: This occurs when a code block finishes its execution but does not release the memory block it occupied.
As shown in the example, useMemo takes a “create” function and a dependency array, and returns a memoized value. Continuing with the naming conventions in the example, the memoizedValue variable will keep the same value in memory as long as the a or b values inside the dependency array do not change. If at least one of the a or b values changes, the “create” function executes and returns a new value. It is used to calculate values that take time to compute and could cause performance issues (computationally expensive calculations).
useCallback, on the other hand, takes an inline callback and a dependency array as arguments, and returns a memoized callback (a memoized callback function) as its return value. Just like with useMemo, the callback held by the memoizedCallback variable only changes when the a or b variables inside the dependency array change. Additionally, useCallback is useful when passing callback functions to child components that are optimized using the reference equality method to prevent unnecessary re-rendering operations.
Using memoization hooks like useMemo and useCallback can introduce overhead. Therefore, they must be used responsibly at points where they are truly needed.
In the JavaScript language, there are two types of equality operators: abstract equality (==) and strict equality (===). React generally uses the Object.is(object1, object2) equality check, but without going into too much detail, we can say that this structure is highly similar to strict equality.nü kullanır fakat çok detaya girmeden bu yapı ile strict equality’nin oldukça benzer olduğunu söyleyebiliriz.
There are 2 situations in React where referential equality is important. One of them is the dependency array and the other is React.memo.
Dependency Array
Some hooks in React include a dependency array in their structure. The most well known ones can be listed as useEffect, useMemo, and useCallback. If we continue with examples through useEffect (examples are kept simple for clarity):
In the example above, it is intended to trigger useEffect when firstProp and secondProp change, and functionA is expected to run again. However, due to the working logic of JavaScript, propObject will be recreated after every render. For this reason, React will think the variable inside useEffect’s dependency array has changed and will execute useEffect even if firstProp and secondProp have not changed. Because of this, unwanted situations can occur, and it is possible to fix this situation in two different ways.
The first of these, and the solution path I would recommend applying if possible, is as follows:
However, in some cases, the props we pass might not be primitive (string, number, etc.). That is, when they have types like function, object, or array, we can fix the problem mentioned above by using useMemo or useCallback.
This usage style actually demonstrates the reason why useMemo and useCallback hooks emerged.
React.memo
If we proceed through an example again:
As seen in the example, our Counter component contains two components named Button. Every time we click one of the Button components, one of the states inside the Counter component will change, so both Button components will be rendered. While the rendering of the clicked Button component (the one whose value we want to change) does not pose a problem for us since we will access the current count value inside it, the other Button component will be re-rendered unnecessarily. To fix this problem, we need to wrap the Button component with React.memo.
React.memo(component, areEqual) is actually a high order component (higher-order component) and takes 2 arguments as shown. While the first argument is the component we want to wrap, the second argument is a custom comparison function (areEqual) that is optional to use. Additionally, while React.memo normally compares the props inside the component superficially (shallowly compare) to decide on the rendering process, we can customize the comparison process thanks to the areEqual function. For detailed information…
After wrapping it in the manner above, the Button component will be re-rendered only when its props change thanks to React.memo. Right here, we need to fix one more small point because the variables given to onClick from the props of the Button component are of non-primitive (function, object, etc.) type, so they will be recreated after the state change and we won’t be able to prevent the unnecessary rendering operation. To fix this situation, useCallback steps in (useMemo can also be used depending on the situation).
With this change we made, we prevent the unnecessary rendering operation and utilize React.memo in a healthy way.
React.memooptimization can introduce overhead, so we must be sure before deciding to use it and use it correctly. Additionally, thanks to React’s fast working structure, unnecessary rendering operations that do not cause serious problems can be ignored.
Performing calculations that can introduce overhead inside useMemo will provide us with performance benefits. The main reason for the emergence of useMemo is to avoid such expensive operations during unnecessary repetitions. To give an example again (even if it is not exactly a practical scenario, it is an example I intended to be clear):
As seen in the code lines above, calculatePrimes will run repeatedly during possible rendering operations, and assuming that calculating prime numbers will introduce overhead, it will place a serious load on our project.
When we wrap it with useMemo this way, it will be calculated only in case the values inside the dependency array change. That is, it will not perform calculations during unnecessary rendering operations and will return the calculated value in memory instead.
I would like to emphasize again that while the use of useMemo and useCallback hooks can provide performance benefits, it can also have overhead. Especially for your team members working on the same project, it can cause confusion, or with a mistake you make in the dependency array, you might prevent memoized values from being cleared by the garbage collector, thereby causing performance issues. If you do your measurements and usage correctly, you can achieve performance benefits as I mentioned at the beginning.
I hope it has been a helpful article 🙂
Author: Mehmet Mutlu
In today’s post, as we approach the end of the first quarter of 2020, we will be examining what npm, YARN, and Pnpm are, their working logic, and their differences.
All three of npm, Pnpm, and Yarn are Package Managers. So, what is this Package Manager? What does it do? It is a tool widely used by developers to share tools, install various modules, and manage the dependencies of these modules.
Modules and dependencies;
In general, all three are managed via the command line.
Even though I had to write NPM in the title, it is a package manager accepted as a standard by Node.js, written entirely in JavaScript as a camelCase abbreviation of Node Package Manager, and thus known as npm, which allows the management of softwares / modules / packages.
To be able to use npm, Node.js must absolutely be installed on your system first. To check whether Node.js and npm are present on your system, you can run the following commands.
node -v
npm -v
If these commands return a version as a response, it means these tools are available on your system.
Package.json
It is a local package database containing information about the packages / modules and dependencies used in the project where it is located. When starting a project, you can create it yourself (with a specific syntax), or it can be created using npm with the init command. In installations done with npm init, the tool will ask you a series of questions and create the file accordingly. If you are going to start a new project with a boilerplate like React Native CLI, package.json will be formed as prepared in the CLI as a result of the CLI’s init process.
Package Installations
{prefix}/lib/node_modules, executable files into {prefix}/bin, and man files into {prefix}/share/man. {prefix} usually corresponds to the /usr/local directory.The installation has the path /usr/local/lib/node_modules/express. When we handle global installation with --save-dev, the relevant definition will also be added to the package.json file as devDependencies.
node_modules folder. Executable files are also kept inside this folder under the ./node_modules/.bin/ path. man files are not processed in local installation.mkdir newproject
cd newproject
npm init -y
npm install express
Following the execution of the command, the node_modules folder will be created in the newproject directory and the express package will be installed inside this folder. After this installation, we can access the package from within our application via ../node_modules/express.
Dependencies
Dependencies is the area where package information will be added when the --save flag is defined along with the install command during installation. These packages are required for production. devDependencies, on the other hand, is the place where the details of the packages will be added with --save-dev. The packages kept here are required for development and testing.
Yarn is a package manager developed as an alternative to npm under the leadership of Facebook software teams, with the support of Google, Exponent, and Tilde companies.
While it generally supports the features of npm, it has also brought new features to solve the security, consistency, and performance problems that gave Facebook engineers a headache.
Yarn has a structure that caches every installed package, so that the package does not need to be downloaded again, and parallelizes the operations performed to maximize resource utilization.
For Yarn installation, we can use another package manager at the system level. Brew or MacPorts can be preferred for macOS.
brew install yarn
#ya da
sudo port install yarn
Of course, the installation process can also be performed without a package manager. To perform the download operation via curl over the command line, this command can be used:
curl -o- -L https://yarnpkg.com/install.sh | bash
For other download and version usage options, you can examine the Yarn > Installation page.
To create a new project with Yarn, we use the yarn init command. When we execute this command in the directory where the project will be run, some information such as name, version, entry point, repository url is requested from us via prompt. Following the entry or skipping of the information, a package.json file is created..
Package Installations
yarn add global [paket-adi]
yarn add command.yarn add [paket-adi]
yarn add [paket-adi]@[paket-versiyonu]
yarn add [paket-adi]@[etiket]
yarn add [paket-adi-1] [paket-adi-2] [paket-adi-3] [paket-adi-4]
pnpm, which is short for performant npm, is a package manager that has all the features of npm and Yarn and shows better performance in many aspects.
It is claimed to be much faster than both npm and Yarn. You can access the benchmark comparisons here.
It uniquely identifies Node Modules on the system using hard links, and then uses symbolic links (symlinks) inside the node_modules folder of each project; meaning you will now have only a single copy of lodash on your system, for example 🎉. This means an incredible space savings on your disk.
Yarn also considered using symbolic links in the past, but due to several reasons, they made another decision and changed their path. In individual trials, I found the performance of pnpm highly successful and it did not cause any problems.
Since its commands are very similar to Yarn, there was no adjustment problem at all.
You can use the link for all details regarding its usage.
It has a “strictness” feature explained in this link. This feature prevents you from using any module that is not in package.json. This stands out as a great feature that allows you to avoid bugs that are hard to track.
npm install -g pnpm
Since pnpm is a drop-in replacement, you can use all commands valid for npm for pnpm as well.
When npm, pnpm, or Yarn needs to install a package, it executes a series of tasks. In npm and pnpm, these tasks are executed per package and sequentially, meaning it waits for a package to be fully installed before moving on to the next. Yarn, on the other hand, improves performance by performing these tasks in parallel.
While the npm tool downloads Node packages sequentially from the central repo, YARN can download multiple packages simultaneously. Thus, it opens the door to faster installations. YARN also has a remote repository named yarnpkg.com.
A package at version a.b.c installed with the YARN tool is additionally stored on your local computer. Thus, when the package at the relevant version is attempted to be downloaded again, it does not need to visit the remote repo.
pnpm creates hard links from the global store to the project’s node_modules folders. Hard links point to the place on the disk where the original files are located. For example, if you have foo as a dependency in your project and it takes up 1MB of space, it will appear to take up 1MB of space in the project’s node_modules folder and the same amount of space in the global store. However, this 1MB is the same space addressed from two different locations on the disk. So the total foo takes up 1MB, not 2MB. Since a new symlink is always created for the same packages, it provides benefits in terms of both speed and disk space.
In the Node module system, every package used to have a version. In the versioning format, the semantic versioning method was preferred. As is known, module dependencies were kept in the file named package.json as name and version range.
For example, the amodule below was dependent on version 1.0.0 and above, and 1.0.7 and below of the lemodule module. It couldn’t do without it.
{
“name”: “amodule”,
…
“dependencies”: {
“lemodule”: “>=1.0.0 <=1.0.7”
}
…
}
However, version ranges specified in this way were open to possible inconsistencies. For example, while version 1.0.2 is installed on your machine, version 1.0.4 might be installed on your friend’s machine. A possible bug that could be found in 1.0.2 could affect the whole setup. Imagine this appearing in a live environment!
Yarn, on the other hand, started using a special file called yarn.lock with a completely different perspective. If yarn.lock is not present in your project, it is created and updated by Yarn. Inside yarn.lock, information such as the exact version, where the package was downloaded from, and checksum info to check data integrity are kept. In this way, same project users are ensured to work with the same module tree at time t. Since packages are also checked via checksum info, you don’t have to worry.
This innovation was very attractive and was not something developers needed to worry about. However, starting from NPM v5.0.0, NPM automatically started creating its own lock file that does the same thing. The name of this file became package-lock.json.
This structure previously developed by Yarn lost its characteristic of being a huge game-changing advantage once npm also turned to the same working logic.
By default, npm is very verbose. For example, when npm install <package> is run, it lists all installed packages recursively. On the other hand, Yarn is not verbose at all. Details can be fetched via other commands, but by default, it lists much less summary, needed information with appropriate emojis (if you are not on Windows).
One of the main reasons Facebook developed Yarn was to better handle npm’s security issues. In npm, packages are allowed to run code automatically and instantly during the installation phase, even automatically and instantly from their dependencies. While this feature has its conveniences, it raises a few security concerns, especially considering the vulnerabilities that can form during the production package building process I mentioned earlier. Conversely, Yarn only installs from your yarn.lock or package.json files. More specifically, yarn.lock ensures that the exact same package is installed on all devices, thus greatly reducing the chance of bugs forming from different versions being installed.
Since these concerns are still in effect at the time of writing, I think Yarn is preferable in terms of security.
Even though it is not a fork taken from npm, Yarn covered npm’s shortcomings in many points. Developed along with the needs and pains of companies that shape technology, Yarn continues to be more preferred and used by the community even after npm’s version 5.0. The only problem here is that Yarn’s roadmap is not clear. Pnpm, on the other hand, makes a difference for developers who actively develop too many projects and have the same libraries in many different projects on their computers. But still, in the trials I made on the React Native project we developed ourselves, Yarn, which offers approximately a 25% performance contribution every time, becomes my choice both with its pioneering structure that solves existing problems and with the efficiency it adds in terms of performance.
So, which one is your choice?
https://www.kochan.io/nodejs/why-should-we-use-pnpm.html
https://medium.com/pnpm/never-ever-forget-to-install-a-dependency-1c39dd3bbb37
https://github.com/pnpm/benchmarks-of-javascript-package-managers
https://smddzcy.com/posts/2019-05-19/npm-vs-yarn-vs-pnpm-package-manager-comparison
https://flaviocopes.com/pnpm/
https://pnpm.js.org/en/about-package-store
https://iamturns.com/yarn-vs-npm-2018/
https://waverleysoftware.com/blog/yarn-vs-npm/
https://www.keycdn.com/blog/npm-vs-yarn
https://github.com/appleboy/npm-vs-yarn
https://dev.to/urfan/npm-vs-yarn-2a2e
https://ceaksan.com/tr/npm-node-package-manager/
Author: Efecan Tekin