<?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: StephenPaul</title>
    <description>The latest articles on DEV Community by StephenPaul (@stephenpaul).</description>
    <link>https://dev.to/stephenpaul</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%2F314367%2F8349ef7a-a6aa-4f69-86ff-6afecadb31fd.jpeg</url>
      <title>DEV Community: StephenPaul</title>
      <link>https://dev.to/stephenpaul</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/stephenpaul"/>
    <language>en</language>
    <item>
      <title>Yes, managed state can be as simple as local state.</title>
      <dc:creator>StephenPaul</dc:creator>
      <pubDate>Sat, 26 Feb 2022 09:07:32 +0000</pubDate>
      <link>https://dev.to/stephenpaul/yes-managed-state-can-be-as-simple-as-local-state-40bp</link>
      <guid>https://dev.to/stephenpaul/yes-managed-state-can-be-as-simple-as-local-state-40bp</guid>
      <description>&lt;p&gt;Ever since the advent of Redux, many libraries have rushed in to address its ergonomic shortcomings by co-locating state, actions, and update logic:&lt;/p&gt;


&lt;div class="ltag_gist-liquid-tag"&gt;
  
&lt;/div&gt;


&lt;p&gt;This pattern is a great step forward, but it can be improved upon:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Within each state update function, we find ourselves repeating similar, but not identical, CRUD logic over and over.&lt;/li&gt;
&lt;li&gt;There is an unnecessary layer of abstraction between components and managed state where a function name may contradict its implementation.&lt;/li&gt;
&lt;li&gt;This extra layer of abstraction discourages us from moving component state into the store where it can be more easily tracked.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;So how does Olik address these issues?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Let’s just jump right in…&lt;/p&gt;


&lt;div class="ltag_gist-liquid-tag"&gt;
  
&lt;/div&gt;



&lt;div class="ltag_gist-liquid-tag"&gt;
  
&lt;/div&gt;


&lt;p&gt;Now, for some interactions:&lt;/p&gt;


&lt;div class="ltag_gist-liquid-tag"&gt;
  
&lt;/div&gt;


&lt;p&gt;Olik is the first state manager to use a completely &lt;strong&gt;fluent API&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;By chaining together a standard set &lt;strong&gt;composable state search and update primitives&lt;/strong&gt;, we can make surgically precise updates to our immutable state tree with zero ambiguity, in complete type-safety, to any depth, right from our components.&lt;/p&gt;

&lt;p&gt;The fluent API allows the library to &lt;strong&gt;describe our actions for us&lt;/strong&gt; with perfect accuracy from within the Devtools extension.&lt;/p&gt;

&lt;p&gt;If you have all features enabled, this library weighs in at 6kb, however, it will arguably have the &lt;strong&gt;least effect on your application bundle size&lt;/strong&gt; because it doesn’t require any infrastructural code, immutable updaters, or immutable update helpers (like Immer).&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Nested stores&lt;/strong&gt; are also supported which help us manage and debug component state with or without our application state.&lt;/p&gt;

&lt;p&gt;Finally, Olik is not built with any particular framework in mind. So far, it can be used &lt;strong&gt;without a framework&lt;/strong&gt;, with &lt;strong&gt;React&lt;/strong&gt;, &lt;strong&gt;Angular&lt;/strong&gt;, or &lt;strong&gt;Svelte&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;For more info, please check out the &lt;a href="https://memeplexx.github.io/olik/"&gt;documentation&lt;/a&gt;.&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
