Exafunction

exafunction

is one of the most widely used hooks in React. Optimizing in React gives you a significant boost in performance and sometimes gets your code rid of nasty bugs. I've encountered many situations where there were performance issues or some difficult-to-find bugs due to incorrect usage of . Here I'll discuss a few of the optimization patterns which are very easy to adhere to yet very effective. useEffect useEffect useEffect 1. Use primitives in the dependency array We often pass JavaScript objects in the dependency array. Although nothing is wrong with doing that, sometimes it makes more sense to destructure the JavaScript object and only pass the specific value to the dependency array of . Let's take a look at an example. Suppose we have a component which takes the object as a prop and fetches the user's transaction data whenever the user changes. We need to get the user's transaction data when the user changes. Our user object looks like this: useEffect useEffect UserInfo user only {
  "id": 123,
  "name": "John Doe",
  "imageURL": "...",
  "isActive": false
} The typical implementation will look like this: function UserInfo({ user }) {

  useEffect(() => {
    getUserData(user.id);
  }, [user]);

  return (
    ...
  );
} This will get user data from the server whenever the user object changes. But looking at the user object, it only makes sense to get the new data when the changes. There could be instances where the user's data changes but the don't, which won't benefit us in making an API call and getting the data from the server again. Let's say the user's was initially and later changed to . In this case, we don't need to get the user's transaction data again because the user is still the same. We can avoid this redundant API call by changing our dependencies. Here's the refactored component using primitive data types: user.id id isActive false true useEffect function UserInfo({ user }) {
  const { id } = user;

  useEffect(() => {
    getUserData(id);
  }, [id]);

  return (
    ...
  );
} With the above optimization of , we will only get the user's transactional data when the user changes. Remember, in dependencies, non-primitives (like objects and arrays) are checked for equality only by reference, not by the value. So the following code will always return : useEffect id useEffect false { name: "Huzaima" } === { name: "Huzaima" } 2. Avoid needless dependencies Sometimes, we use to derive a new state from our current state. Suppose we've a counter which totals the length of the string every time the input value is updated. We can implement that like this: useEffect function CharacterCounter() {
  const [inputValue, setInputValue] = useState("");
  const [compoundStringLength, setCompoundStringLength] = useState(0);

  useEffect(() => {
    if (inputValue) {
      setCompoundStringLength(compoundStringLength + inputValue.length);
    }
  }, [inputValue, compoundStringLength]);

  return (
    ...
  );
} The above code results in being executed infinitely. Why? Because of the incorrect dependency. We're updating inside the and using the same as a dependency. How do we solve this problem? We need to use inside the for computation, so we can't get rid of it. But what we can do is remove it from the dependency array. You might think this will result in an incorrect value of due to being a closure. You're right... and wrong. This is correct because is a closure, so we won't get the correct value of if we don't use it in the dependency array. Still, there's a way of getting the correct value of without specifying it in the dependency array. The state setter function ( ) doesn't only accept value but also a function. The signature of that function looks like this: useEffect compoundStringLength useEffect compoundStringLength useEffect compoundStringLength useEffect useEffect compoundStringLength compoundStringLength setCompoundStringLength setCompoundStringLength: (currentStateValue) => newStateValue; We can leverage the above function signature in the to get the correct value of for our computations . The refactored optimization of looks like this: useEffect compoundStringLength without specifying it as a dependency useEffect function CharacterCounter() {
  const [inputValue, setInputValue] = useState("");
  const [compoundStringLength, setCompoundStringLength] = useState(0);

  useEffect(() => {
    if (inputValue) {
      setCompoundStringLength(
        (compoundStringLength) => compoundStringLength + inputValue.length
      );
    }
  }, [inputValue]);

  return (
    ...
  );
} 3. Hoist functions Any unmemoized function that you define inside the component is recreated on every render. A very naive example is this: function EmailValidate() {
  const [email, setEmail] = useState("");

  const isEmailValid = (input) => {
    const regex =
      /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

    if (regex.test(input)) return "Email is valid";
    return "Email is invalid";
  };

  return (
    <>
      <input value={email} onChange={(event) => setEmail(event.target.value)} />
      <p>{isEmailValid(email)}</p>
    </>
  );
} Here you can see that the function is a pure function and doesn't depend on the component's props and/or state. We can easily optimize this by extracting the function outside the component. Rewriting the above component will look like this: isEmailValid const isEmailValid = (input) => {
  const regex =
    /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

  if (regex.test(input)) return "Email is valid";
  return "Email is invalid";
};

function EmailValidate() {
  const [email, setEmail] = useState("");

  return (
    <>
      <input value={email} onChange={(event) => setEmail(event.target.value)} />
      <p>{isEmailValid(email)}</p>
    </>
  );
} 4. Clean up The primary purpose of is to handle side effects. Sometimes you have to clean up those side effects like event handler subscriptions or observables. You can return the function having clean-up logic from the function inside . Let us take an example of an input field which should clear when the user presses the key. We can do so like this: useEffect useEffect Escape function Input() {
  const [input, setInput] = useState("");

  const escFunction = useCallback((event) => {
    if (event.key === "Escape") {
      setInput("");
    }
  }, []);

  useEffect(() => {
    document.addEventListener("keydown", escFunction, false);

    return () => {
      document.removeEventListener("keydown", escFunction, false);
    };
  }, [escFunction]);

  return (
    <>
      <input value={input} onChange={(event) => setInput(event.target.value)} />
    </>
  );
} In the above code, we're returning a function from inside the . That function unsubscribes the event listener, saving us from nasty memory leak problems. useEffect keydown 5. Use multiple effects to separate concerns Ever heard of divide and conquer? Yup! That's precisely what we need to do here. Aka , a widely practiced principle in software engineering. in , i.e. using different for every use case. Suppose we've a component which gets and in props. We make an API call to get user and organization data based on the props. We can write like this: separation of concerns React team advocates for separation of concerns useEffect useEffect userId organizationId useEffect useEffect(() => {
  getUser(userId);
  getOrganization(organizationId);
}, [userId, organizationId]); The above will work fine. But there's one fundamental problem. If the change but the don't, will still get called. Why? Because we've added two separate concerns in a single . We need to segregate them into two different . We can rewrite it like this: useEffect userId organizationId getOrganization useEffect useEffect useEffect(() => {
  getUser(userId);
}, [userId]);

useEffect(() => {
  getOrganization(organizationId);
}, [organizationId]); 6. Custom hooks Custom hooks are a great way of extracting side effects, which can be reused by many other components. It's also an elegant way of organizing your code. Suppose we've a custom hook to return details about the input string. We can write that custom hook like this: function useStringDescription(inputValue) {
  if (!inputValue) {
    return defaultValue;
  } else {
    const wordCount = inputValue.trim().split(/\s+/).length;
    const noOfVowels = inputValue.match(/[aeiou]/gi)?.length || 0;
    return {
      wordCount,
      noOfVowels,
    };
  }
} The hook returns the number of vowels and the word count of a string passed in the argument. We can use this hook like this: useStringDescription function App() {
  const [inputValue, setInputValue] = useState("");
  const stringDescription = useStringDescription(inputValue);
  const { wordCount, noOfVowels } = stringDescription;

  useEffect(() => {
    console.log("stringDescription changed", stringDescription);
  }, [stringDescription]);

  return (
    ...
  );
} Let's try to use the above setup and see how many times the is executed. useEffect You can see that is called even when the object's value doesn't change. We can destructure the object as defined in the 1st rule of this article, or we can optimize our custom hook like this: useEffect stringDescription stringDescription function useStringDescription(inputValue) {
  const [stringDescription, setStringDescription] = useState(defaultValue);

  useEffect(() => {
    if (!inputValue) {
      setStringDescription(defaultValue);
    } else {
      const wordCount = inputValue.trim().split(/\s+/).length;
      const noOfVowels = inputValue.match(/[aeiou]/gi)?.length || 0;

      if (
        wordCount !== stringDescription.wordCount ||
        noOfVowels !== stringDescription.noOfVowels
      ) {
        setStringDescription({
          wordCount,
          noOfVowels,
        });
      }
    }
  }, [inputValue, stringDescription.noOfVowels, stringDescription.wordCount]);

  return stringDescription;
} Now, we're updating the state when any value changes. Let's check out the results: See? didn't get called needlessly because the referential equality holds. useEffect These were the bunch of optimizations we can use to make the usage of hooks more effective and get rid of nasty and notoriously hard to find bugs caused due to incorrect usage of hooks. Optimizing in React also gives you a boost in performance. What are your secret recipes? Let me know on . And don't forget to read my previous blog about . useEffect useEffect useEffect Twitter promise speed up Also published here.

How to Take Full Advantage of useEffect in React

A common workflow in vim is to use multiple windows to view and edit various files at the same time. Once opened though, the size of each window often remains unchanged unless explicitly resized. A nicer workflow would be for the focused window's width to automatically expand. The Code This behavoir requires surprisingly little vim script and has become one of my favorite additions. It's accomplished with the following snippet that uses an autogroup to call a function on the vim event. WinEnter ReduceNoise
    autocmd! WinEnter * : ResizeSplits() END = = augroup " Automatically resize active split to 85 width autocmd call augroup ! function ResizeSplits () set winwidth 85 wincmd endfunction The first line of the function sets to 85. This settings controls the width for the active window; the number represents the number of columns for the active window including the sign and line number columns. If those require 5 columns and is set to 85, 80 columns are used for the text. winwidth winwidth The second line, , equalizes the width and height for all the other unfocused windows; see for more information and some other great window commands. wincmd = : h wincmd Beyond Resizing The above is a slimmed down version of a more practical implementation. Controlling other window settings can reduce additional noise on unfocused windows increasing your signal to noise ratio fo r your active work. Some additional ideas include: Display absolute line numbers in unfocused windows and relative line numbers only in the focused window Only display the sign column in the focused window Only show the cursor line in the focused window Disabling syntax settings of the unfocused windows Enabling these settings is easily done by extending the above autogroup to include some additional auto commands like the ones shown below. WinEnter * cursorline WinEnter * signcolumn=auto WinLeave * nocursorline WinLeave * signcolumn= autocmd setlocal autocmd setlocal autocmd setlocal autocmd setlocal no When a window is entered, the and are enabled. Unfocused windows disable these settings. cursorline signcolumn Whatever you do and don't like to see in focused and unfocused windows is now in your control. This can include status lines for active and inactive windows through ( ). each window can have its own status line setup: see an example here in my vimrc The Gotchas The autocommands and resizing function work well in most cases, but may have some unintended effects. Windows created by plugins like NERDTree or to display the quick fix and location list may expand unexpectedly when focused. One resolution to this unintended behvaoir is to add some if statements to the resize function to only execute if the active window's file type is not NERDTree, quick fix, or location list. You may not want to run when on these windows as it equalizes not just the width but also the height of all open windows. wincmd = Despite these (minor) shortcomings (most of which can be accounted for and fixed), this has become one of my favorite and most useful settings. Its a pattern you won't know you missed until you had it. As always, along with the rest of my . here's my vimrc for these settings dotfiles At least one plugin has been created for this behavior: . If plugins are more appealing to your set up it can support some additional cool features. Lens.vim

Automatic Window Resizing in Vim

Author: Yurii Vlasiuk Today we want to share our experience of implementing the backend tool for the generation of graphical banners from HTML templates. ’s customer was interested in automation of advertisement banners customisation based on the prepared templates. Basically, you have an index.html with fields where you can insert different components e.g. buttons, images or text. So I will tell about approaches we’ve used to implement such functionality. For our project we chose PhantomJS. You may argue that there are more innovative solutions in the npm repository. But when we started, none of these libraries was stable or well documented yet ( , for example, — a Node.js library that provides a high-level to control headless Chromium-based engines; among its most notable features — awesome capabilities for taking screenshots). The project’s specs required a great deal of stability. That’s why we decided to employ the tried and well-documented PhantomJS. The task was to create a function for taking screenshots with headless Chrome as described on Medium in the by . WebbyLab Puppeteer API article David Schnurr Ok, enough with introductions. Let’s have a closer look at the framework we’ve decided to use. ( ) is a headless WebKit browser scriptable with a API. PhantomJS https://github.com/ariya/phantomjs JavaScript A list of features according to creators is as follows: Headless web testing; Page automation; Screen capture; Network monitoring. I will not go deeper into each of them but concentrate on the task and approaches used for its resolution instead. The task implied implementing the following functions: HTML template-based image generation (which could be customized); image compression — to fit certain size restrictions; zoom images to gain quality improvement for Retina screens. Preparation To set the stage up, you first need to download and install PhantomJS using npm. I’ve set up small express server with two routes — one for static hosting and another for sending generation requests (the complete example is available at my ). Github First, we must create a core class for image generation. Start by creating an instance of Phantom and use it for creating the page, which will provide the image rendering on our back-end. Next, we must set the properties to our page — size of a page using property and to define coordinates of the coordinates of the rectangle to render: viewportSize clipRect Then we need to open the page which will return the status of operation: const status = await page.open(config.templatePath); Also there it is a possibility of evaluating JavaScript code in the context of the web page. For this, function is used, which accepts another function as an argument. We used to make changes in templates before rendering to images. evaluate() evalFunction await page.evaluate(evalFunction); But for the beginning we will leave it out as it is optional and actually not needed for getting an image. The last step which is needed for screenshotting in headless mode is launching the actual rendering and exiting our instance of PhantomJS: Also good practice is to check if the image was successfully created and throw ‘Error’ otherwise. This allows handling situations when Phantom haven’t been able to open a template. Now we can collect all the pieces into the image generation class. We separated the operation of this class to three parts: creating the page, setting its size, and generating image. Here’s the listing: Thus, basic functionality for rendering an image from the template is ready and actually, this is already a working example. If you call the method passing to it the page sizes and config object with keys templatePath (location of HTML template which you want to render into an image) and destinationPath (location of the output image file), this will create the image in the JPEG format. Further, we will extend this example with additional options. generate() Error Handling and Debugging Method returns the status of the operation. A good practice is checking if opening the page ended is and throw an exception otherwise. This will allow handling situations when Phantom hasn’t been able to open a template. page.open() success To control what is happening during page rendering in the headless mode, I’ve added logging to Phantom page instance using property to output the page messages to the terminal console. This peace can be added to our method of class. onConsoleMessage _createPage() ImageGenerator Template Customization For the example, I’ve created a simple template using the image with the meme, that was popular in summer of 2017. Here is the listing of ‘index.html’: CSS styles are needed only for the positioning and sizing of textual blocks. All files related to the template are located in ‘static/templates’ directory. When you’ve finished preparing the template, it’s time to extend the class example with function and add any JS scripts you might additionally require to the template. Keep in mind that any JavaScript code in the template would be evaluated and executed by Phantom, which doesn’t recognize any of the ES6-specific features (e.g. no string templating and only concatenation). I personally find it not fun. Also, Phantom does not support some CSS properties which are widely used in modern browsers. For example, if you are keen on using Flexbox, you can forget about it when prepare templates - while rendering them with Phantom, all the unsupported features will be ignored or even cause an error. evaluate I think the easiest way to customise page texts in eval function is using and then replacing in selected node or changing property in the tag. Also, I’ve declared this function not in the class itself but right before calling the method. This provides the flexibility to pass different functions in different cases. For example, you can pass such function to : getElementById innerHtml src img imageGenerator generate() page.evaluate() As you may already notice, you also should standardise the format of your templates and content IDs because they would be used by the evaluation function. That’s why better to keep naming conventions consistent across all templates so as not to write different evaluate functions for each of them. The second argument of is used to pass parameters to : page.evaluate() evaluateFunc await page.evaluate(evaluateFunc, config); Image Compression The project, where we used PhantomJS, had another requirement for output images. There were file size and image dimensions (fixed height and width) restrictions on the platform for which the project was developed. Images should be as high-quality as possible while satisfying the restrictions. PhantomJS provides an option to choose the quality (or compression level) for PNG and JPEG formats: await page.render(config.destinationPath, { format: 'jpeg', quality: ‘96’ }); A range is between 0 and 100, the default value being 75. Thus, we had to calculate the needed compression level before rendering somehow. For most cases, I’ve used an approach of calculating value by resolving simple proportion for the content combination. It gave me the biggest image size and the empirically-found value of quality parameter. Using this value, it became possible to calculate the coefficient (of course, we should not forget that compression level and output file size are inversely proportional). In the following example, 96 is the level of compression, is a multiplication of height and width of the output image (known value), and is the level of compression we seek: size x Next, we extended with the method for calculating the compression level depending on the picture dimensions: imageGenerator But this was not all. Other content (e.g. different backgrounds) may also exceed the size restriction. Moreover, upon compression, file size does not decrease linearly, which is illustrated by the following graph (dependency of quality to file size): In the end, we employed another approach, still rather straightforward but working. If the content exceeds the size limit, we start iterating image rendering decrementing quality step by step and returning the found quality value from method: generate Combination of both approaches — pre-calculated factor and iterative quality decrementing — gives better results in performance because image rendering is a high-load operation. In the practice, the acceptable result was achieved immediately with static coefficient in most cases and only some pictures required 2–3 additional iterations (not a bad result, I think). Picture Quality Improvement Another interesting task was improving the resulting images’ quality. Due to limitations, rendering in Phantom produces the compressed images. That’s why the HTML template opened in browser was looking better than rendered image with fixed dimension even with quality set to 100. The compressed image never looks as sharp as original thanks to the higher dimension of the latter — twice or even more times. It is apparent in the example below — on the left is an image generated by Phantom with the resolution of 1152*768 and quality set to 100 and on the right is the original, opened in a browser: In the left picture, you can notice the pixel grain, which becomes even more notable when zooming. That’s why despite the image dimension limits, we also included the possibility to generate bigger pictures but with the same file size restriction. It was possible because some of the pictures did not reach size limit at all in their normal dimensions. By the way, with Phantom, it could be done simply. For this, property is set, which specifies how many times the image should be scaled: zoomFactor page.property('zoomFactor', 2); Both height and width must be multiplied by this value, otherwise only a cropped part of the zoomed image would be rendered. To make this optional, we passed the flag to switch the zooming mode on to arguments of method of class: generate ImageGenerator Events Another powerful mechanism in PhantomJS that can be used in template rendering is a page event system. It could be useful in case when some reactions are defined in the template — on hover or mouse click, for instance. Here is how to initiate the mouse click event at (10, 10) coordinates in the template: await page.sendEvent('click', 10, 10, 'left'); Other supported types of events are ‘mouseup’, ‘mousedown’, ‘mousemove’, ‘doubleclick’. Two arguments representing the mouse position for the event are optional. And the last one indicates, which mouse button should be “clicked”, by default it is left. Also, Phantom supports sending keyboard events but I will not cover them in this article. If you’re interested, you can read more on this in the library’s . documentation Originally published at blog.webbylab.com .

Stories, News & Mentions about EXAFUNCTION

Exafunction’s Stories on HackerNoon