<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Paweł Sułkowski</title>
    <description>The latest articles on DEV Community by Paweł Sułkowski (@sulkowski).</description>
    <link>https://dev.to/sulkowski</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F639748%2F021f6925-b5a4-4563-87d6-a49b1a0d9e7f.jpg</url>
      <title>DEV Community: Paweł Sułkowski</title>
      <link>https://dev.to/sulkowski</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/sulkowski"/>
    <language>en</language>
    <item>
      <title>useSelector performance pitfall</title>
      <dc:creator>Paweł Sułkowski</dc:creator>
      <pubDate>Sat, 02 Mar 2024 14:09:19 +0000</pubDate>
      <link>https://dev.to/sulkowski/useselector-performance-pitfall-4i3</link>
      <guid>https://dev.to/sulkowski/useselector-performance-pitfall-4i3</guid>
      <description>&lt;p&gt;I used to think of Redux as a straightforward state management tool: dispatch an action, reducer updates the state, and components re-render. That mental model served me well — until our app grew to handle a surge of customer data and real-time collaboration features. Suddenly, the performance took a nosedive.&lt;/p&gt;

&lt;p&gt;Diving deep into the problems, we traced several bottlenecks. One surprising finding was in how Redux’s subscription works. Each time we used &lt;code&gt;useSelector&lt;/code&gt;, we essentially told Redux, &lt;em&gt;„Hey, keep me updated on &lt;strong&gt;any change&lt;/strong&gt; in the store“&lt;/em&gt;. This was significant because as our app scaled, &lt;strong&gt;the number of subscriptions&lt;/strong&gt; and &lt;strong&gt;frequency of updates&lt;/strong&gt; led to a cascade effect of executing dozens of selectors. &lt;/p&gt;

&lt;p&gt;After looking closer into them, we uncovered a few culprits:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;We under-utilized memorization; Some selectors repeatedly performed costly operations by iterating over extensive collections to filter and combine data.&lt;/li&gt;
&lt;li&gt;For parametrized selectors, we didn’t use memorization properly (nuances of &lt;code&gt;reselect&lt;/code&gt; vs. &lt;code&gt;re-reselect&lt;/code&gt;).&lt;/li&gt;
&lt;li&gt;Array-based approach for collections wasn't optimal for lookups (e.g., finding objects by ID).&lt;/li&gt;
&lt;li&gt;Over-fetching data, and not cleaning up the state after changing contexts resulted in bloating the store with unused data.&lt;/li&gt;
&lt;li&gt;Selectors were running even for off-screen elements.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Once we knew types of our issues, it was &lt;em&gt;relatively&lt;/em&gt; easy to come up with solutions to improve the situation. Here is the list of the main changes we've introduced:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;More extensive use of &lt;code&gt;reselect&lt;/code&gt; and &lt;code&gt;re-reselect&lt;/code&gt; to avoid redundant computations and to account for selectors returning new objects by a reference.&lt;/li&gt;
&lt;li&gt;Refactored store away from arrays, adopting a key/value structure for faster lookups by ID.&lt;/li&gt;
&lt;li&gt;For real-time updates, we throttled them and combined into batched updates to avoid dispatching sequential, and atomic updates.&lt;/li&gt;
&lt;li&gt;Started fetching data more conservatively to avoid storing data our users don’t need.&lt;/li&gt;
&lt;li&gt;Last but not least, we hid off-screen elements to reduce active subscriptions.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  Lessons
&lt;/h2&gt;

&lt;p&gt;Performance optimization is a complex puzzle, and solutions often depend on multiple factors. In our case, taking a step back to gain a holistic understanding of our tools, system, and usage patterns was the key to identifying and implementing effective optimizations.&lt;/p&gt;

&lt;p&gt;I hope you find it useful! 🙂&lt;/p&gt;

</description>
      <category>redux</category>
      <category>react</category>
      <category>performance</category>
    </item>
    <item>
      <title>My journey to better lightning talks</title>
      <dc:creator>Paweł Sułkowski</dc:creator>
      <pubDate>Mon, 20 Nov 2023 18:43:42 +0000</pubDate>
      <link>https://dev.to/sulkowski/my-journey-to-better-lightning-talks-5hj0</link>
      <guid>https://dev.to/sulkowski/my-journey-to-better-lightning-talks-5hj0</guid>
      <description>&lt;p&gt;&lt;strong&gt;TL;DR:&lt;/strong&gt; By focusing on a clear structure, big picture, storytelling, minimalistic design, and limiting technical details, I improved my lightning talks by making them more practical and engaging.&lt;/p&gt;




&lt;h4&gt;
  
  
  Context
&lt;/h4&gt;

&lt;p&gt;In my previous projects, our team regularly organized lightning talks where we shared knowledge about tools, technologies, and projects we'd worked on.&lt;/p&gt;

&lt;p&gt;Although I was eager to share my knowledge, my presentations were often overloaded with details, ran over time, and I was losing team's attention and interest.&lt;/p&gt;

&lt;p&gt;Recognizing this, I decided to take a step back to find a better approach. Through experimentation, I found a few steps that helped me more effectively convey my thoughts and knowledge.&lt;/p&gt;

&lt;h4&gt;
  
  
  Solution
&lt;/h4&gt;

&lt;ol&gt;
&lt;li&gt;I start by defining key points to share and structuring them to ensure the content is understandable and easy to follow.&lt;/li&gt;
&lt;li&gt;Next, I break down things into layers, processes, workflows, and systems, then showcase how they fit together, exchange information, and change their state. Even though I like jumping into details, I realized that in most cases focusing on the big picture is more helpful.&lt;/li&gt;
&lt;li&gt;When designing a presentation, I limit myself to simple elements like text or stickies and a few colors, like shades of grey, to ensure my focus is on the content, not the layout or fancy effects. I'm also a huge fan of whiteboards, so whenever possible, I use them as my go-to tool as they give me freedom and flexibility in my thinking and design processes.&lt;/li&gt;
&lt;li&gt;Once I have the content, I figure out how to turn it into a story, where I gradually reveal its details. It's meant to avoid cognitive murder, help absorb the content, understand the topic, and keep the team curious and engaged.&lt;/li&gt;
&lt;li&gt;Finally, while sharing technical details is essential, code examples are often unnecessary. But, if they are a must, I reduce them to the simplest possible version.&lt;/li&gt;
&lt;/ol&gt;

&lt;h4&gt;
  
  
  Final thoughts
&lt;/h4&gt;

&lt;p&gt;Focusing on improving my lightning talks helped me in more ways than expected. Not only did my presentations improve, but these changes also made a difference in my daily work, in how I work on projects, but also in how I communicate with the team. &lt;/p&gt;

&lt;p&gt;While these methods have been particularly helpful for me, it's important to remember that there are many ways to prepare and run presentations, and what works best can vary from person to person.&lt;/p&gt;

</description>
      <category>productivity</category>
      <category>softwareengineering</category>
      <category>publicspeaking</category>
    </item>
  </channel>
</rss>
