<?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: Ross Creighton</title>
    <description>The latest articles on DEV Community by Ross Creighton (@ross).</description>
    <link>https://dev.to/ross</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%2F2017%2F083e86b1-daa3-4881-a139-86999fafa050.jpg</url>
      <title>DEV Community: Ross Creighton</title>
      <link>https://dev.to/ross</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/ross"/>
    <language>en</language>
    <item>
      <title>[Boost]</title>
      <dc:creator>Ross Creighton</dc:creator>
      <pubDate>Mon, 02 Dec 2024 03:10:04 +0000</pubDate>
      <link>https://dev.to/ross/-flg</link>
      <guid>https://dev.to/ross/-flg</guid>
      <description>&lt;div class="ltag__link"&gt;
  &lt;a href="/alp" class="ltag__link__link"&gt;
    &lt;div class="ltag__link__pic"&gt;
      &lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F583286%2F388dcc77-638a-47db-9dee-8f54f037b45c.jpg" alt="alp"&gt;
    &lt;/div&gt;
  &lt;/a&gt;
  &lt;a href="/alp/a-data-pipeline-for-1-million-movies-and-10-million-streaming-links-1h6a" class="ltag__link__link"&gt;
    &lt;div class="ltag__link__content"&gt;
      &lt;h2&gt;A Data Pipeline for 1 million movies and 10 million streaming links&lt;/h2&gt;
      &lt;h3&gt;Alper Ortac ・ Dec 1&lt;/h3&gt;
      &lt;div class="ltag__link__taglist"&gt;
        &lt;span class="ltag__link__tag"&gt;#windmill&lt;/span&gt;
        &lt;span class="ltag__link__tag"&gt;#python&lt;/span&gt;
        &lt;span class="ltag__link__tag"&gt;#movies&lt;/span&gt;
        &lt;span class="ltag__link__tag"&gt;#goodwatch&lt;/span&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/a&gt;
&lt;/div&gt;


</description>
    </item>
    <item>
      <title>Code quality is overrated</title>
      <dc:creator>Ross Creighton</dc:creator>
      <pubDate>Wed, 23 Jan 2019 20:10:18 +0000</pubDate>
      <link>https://dev.to/ross/code-quality-is-overrated-3bnn</link>
      <guid>https://dev.to/ross/code-quality-is-overrated-3bnn</guid>
      <description>&lt;p&gt;If you're like me, you worry a lot about whether the code you write is "good enough".&lt;/p&gt;

&lt;p&gt;For the past year I've been building &lt;a href="https://gush.com"&gt;Gush&lt;/a&gt;, a personalized guide for things to do in NYC, which is currently in private beta. I'm constantly asking questions like "is this properly abstracted?", "does this have enough documentation?", "is this easy to reuse?", "is this maintainable in the long term?", or "is there a smarter way to write this?". Answering these questions is a valuable exercise, no doubt.&lt;/p&gt;

&lt;p&gt;But Gush's future is uncertain. Code quality doesn't matter if we fail to gain user traction. I've had to learn to stop improving my code a bit earlier than I might like, because user's don't care how good the code is. For situations like mine, I think "code quality" needs a slightly different definition.&lt;/p&gt;

&lt;p&gt;The first measure of code quality should be "does it work?". The next most important measure of quality is "does it provide an excellent experience for our users?". Until you prove that your product has traction, all other measures of quality are nice-to-have's. &lt;/p&gt;

&lt;p&gt;Spending time on code quality is a privilege - one that must be earned by building a product that people love.&lt;/p&gt;

&lt;p&gt;I'm not advocating sloppy code. I care about code quality and I do everything in my power to avoid accumulating tech debt. But for early stage projects, you have to find a balance, and that balance isn't always pretty.&lt;/p&gt;

</description>
      <category>startup</category>
      <category>culture</category>
      <category>productivity</category>
      <category>programming</category>
    </item>
    <item>
      <title>CSS Flexbox in 30 seconds</title>
      <dc:creator>Ross Creighton</dc:creator>
      <pubDate>Mon, 15 Jan 2018 06:57:01 +0000</pubDate>
      <link>https://dev.to/ross/css-flexbox-in-30-seconds-2j2n</link>
      <guid>https://dev.to/ross/css-flexbox-in-30-seconds-2j2n</guid>
      <description>&lt;p&gt;Flexbox is a CSS layout mode that aims to simplify responsive layout development. Flexbox layouts use two types of elements: flex containers and flex items. Flex containers have a primary axis (called the main axis) and a secondary axis (called the cross axis). Flex items are nested inside flex containers and can be aligned, sized, scaled, and ordered relative to the main or cross axis of the container. The visual order of flex items on the screen is independent of their HTML source order.&lt;/p&gt;

</description>
      <category>css</category>
      <category>inthirtyseconds</category>
    </item>
    <item>
      <title>CSS Modules in 30 seconds</title>
      <dc:creator>Ross Creighton</dc:creator>
      <pubDate>Fri, 12 Jan 2018 16:50:24 +0000</pubDate>
      <link>https://dev.to/ross/css-modules-in-30-seconds-5b94</link>
      <guid>https://dev.to/ross/css-modules-in-30-seconds-5b94</guid>
      <description>&lt;p&gt;CSS Modules allows us to write CSS rules that are restricted to a certain part of the UI. It is not an official specification or browser implementation, but rather a process enabled by a build tool like Webpack. In contrast to a regular CSS selector, which can match any element, a CSS Modules selector can only match elements in a specific part of the UI (e.g. in a specific React Component). Build tools accomplish this by transforming the selectors we write into new, globally unique selectors and then applying the new selector to the associated UI element. &lt;/p&gt;

</description>
      <category>css</category>
      <category>inthirtyseconds</category>
    </item>
    <item>
      <title>Why React Needs Redux</title>
      <dc:creator>Ross Creighton</dc:creator>
      <pubDate>Tue, 05 Dec 2017 07:18:03 +0000</pubDate>
      <link>https://dev.to/ross/why-react-needs-redux-b09</link>
      <guid>https://dev.to/ross/why-react-needs-redux-b09</guid>
      <description>&lt;h1&gt;
  
  
  Background and Component state
&lt;/h1&gt;

&lt;p&gt;Sometimes the UI code that a Component generates needs to change after the initial render (e.g. in response to a user interaction or network request). To enable these dynamic UI’s, React gives us Component state. Component state is an extremely useful and well-designed feature, but when used incorrectly, allows us to create brittle Components that are a nightmare to maintain, reuse, and test.&lt;/p&gt;

&lt;h1&gt;
  
  
  The problem
&lt;/h1&gt;

&lt;p&gt;The problem arises when we attempt to use Component state to manage the state of an entire application. In real-world apps, certain types of state need to be shared between Components. A common example of this is authentication state, because many different Components of an app need to know if a user is logged in and who that user is. Let’s consider two  components in an imaginary application: &lt;code&gt;&amp;lt;UserMenu /&amp;gt;&lt;/code&gt;, a dropdown user menu that lives somewhere in the nav bar, and &lt;code&gt;&amp;lt;LikeButton /&amp;gt;&lt;/code&gt;, a button somewhere in the body of the page that allows a user to like a post. Both of these components need to know who is logged in. It is possible to share the user data between these two components by keeping it in a parent's component state, e.g. &lt;code&gt;&amp;lt;App /&amp;gt;&lt;/code&gt;, and passing it down through the component hierarchy as props. Unless an application is extremely small or mostly stateless, this becomes a headache very quickly.&lt;/p&gt;

&lt;p&gt;When we take the shared component state approach, we end up creating large quantities of "pass-through" props, which do little else other than shuttle along data and clutter up all the components in between. On top of that, the end users of these pass-through props (UserMenu and LikeButton) end up with a large prop surface area. In order for them to render, their parent must supply them with the many props that they need. &lt;/p&gt;

&lt;p&gt;Components that require many props are more difficult to reuse. (&lt;code&gt;&amp;lt;LikeButton /&amp;gt;&lt;/code&gt; vs &lt;code&gt;&amp;lt;LikeButton loggedIn={this.props.loggedIn} username={this.props.username} likePost={this.props.likePost} /&amp;gt;&lt;/code&gt;). All those props have to be typed out every time we want to use a &lt;code&gt;LikeButton&lt;/code&gt;. This problem becomes even worse when testing a component, as each function and piece of data passed into a Component as a prop may need to be mocked when being tested.&lt;/p&gt;

&lt;p&gt;Things get even more messy when a Component needs to change the shared component state. Imagine this: &lt;code&gt;&amp;lt;App /&amp;gt;&lt;/code&gt; passes an &lt;code&gt;onLike&lt;/code&gt; callback through the component hierarchy down to &lt;code&gt;&amp;lt;LikeButton /&amp;gt;&lt;/code&gt;. When a user clicks the button, &lt;code&gt;&amp;lt;LikeButton /&amp;gt;&lt;/code&gt; makes a network request and then calls &lt;code&gt;onLike&lt;/code&gt;. The callback calls &lt;code&gt;setState&lt;/code&gt; on &lt;code&gt;&amp;lt;App /&amp;gt;&lt;/code&gt; to record the change to the shared state. This type of arrangement creates complicated relationships between components that are very difficult to understand and change. &lt;/p&gt;

&lt;h1&gt;
  
  
  How Redux helps
&lt;/h1&gt;

&lt;p&gt;With Redux, all of our data lives in a single Store, and Components can subscribe to only the data they need, from wherever they are being mounted. The shared state previously stored in &lt;code&gt;&amp;lt;App /&amp;gt;&lt;/code&gt; in our example is moved to the Redux store. When &lt;code&gt;&amp;lt;LikeButton /&amp;gt;&lt;/code&gt; mounts, it simply subscribes to the data that it needs from the Store - the programmer doesn’t have to type out a bunch of props being passed in from it’s parent. And if &lt;code&gt;&amp;lt;LikeButton /&amp;gt;&lt;/code&gt; needs to change shared application state, it can import actions or action creators directly and dispatch them. Instead of a method on &lt;code&gt;&amp;lt;App /&amp;gt;&lt;/code&gt;, &lt;code&gt;onLike&lt;/code&gt;  becomes an action creator.&lt;/p&gt;

&lt;h1&gt;
  
  
  Conclusion
&lt;/h1&gt;

&lt;p&gt;Redux helps us do less typing, write less complicated code, and develop Components that are free of coupling and easy to reuse. &lt;/p&gt;

</description>
      <category>javascript</category>
      <category>redux</category>
      <category>react</category>
    </item>
    <item>
      <title>ReduxJS in 30 seconds</title>
      <dc:creator>Ross Creighton</dc:creator>
      <pubDate>Mon, 09 Oct 2017 03:00:42 +0000</pubDate>
      <link>https://dev.to/ross/reduxjs-in-30-seconds-5hj</link>
      <guid>https://dev.to/ross/reduxjs-in-30-seconds-5hj</guid>
      <description>&lt;p&gt;Redux is a JavaScript library that aims to simplify how we manage stateful data. Redux keeps all of our data in a single JS object called the &lt;code&gt;Store&lt;/code&gt;. A single function, the &lt;code&gt;reducer&lt;/code&gt;, is responsible for making modifications to the Store. We trigger the reducer by 'dispatching' an &lt;code&gt;action&lt;/code&gt; - a JS object that describes how our data should change. The reducer function receives the action as an argument and makes changes accordingly. Other parts of the code (usually React Components) can subscribe to data in the Store. When data changes, Redux notifies subscribers of the change.&lt;/p&gt;

</description>
      <category>javascript</category>
      <category>redux</category>
      <category>react</category>
      <category>inthirtyseconds</category>
    </item>
    <item>
      <title>ReactJS in 30 seconds</title>
      <dc:creator>Ross Creighton</dc:creator>
      <pubDate>Tue, 03 Oct 2017 16:16:19 +0000</pubDate>
      <link>https://dev.to/ross/reactjs-in-30-seconds-d4o</link>
      <guid>https://dev.to/ross/reactjs-in-30-seconds-d4o</guid>
      <description>&lt;p&gt;React is a JavaScript library that aims to help us write user interface(UI) code. React’s fundamental building block is the &lt;code&gt;Component&lt;/code&gt; which, in its simplest form, is a JavaScript function that generates UI code (usually HTML). The generated UI code is then rendered by the device. A Component represents a small portion of the UI. Many Components are used together, or &lt;em&gt;composed&lt;/em&gt;, to create entire views or applications. React Components can receive data that is used to generate the UI code. Whenever a Component’s data changes, it will automatically regenerate the UI code.&lt;/p&gt;

</description>
      <category>react</category>
      <category>javascript</category>
      <category>beginners</category>
      <category>inthirtyseconds</category>
    </item>
  </channel>
</rss>
