Hi there, I’m Ryan; a freelance, self-employed web developer — which ultimately means I’m a company of one.

I recently stumbled upon the following tweet from a fellow freelancer that asked — How do you make long-term friends as freelancer?

James Good 🏔️🇬🇧 on Twitter

How do you make long-term friends as a freelancer, that aren't the friends you knew in school? It's not something I discuss often, but 2018 was a lonely year, and it's one of my commitments to not let 2019 go the same way. Any advice is appreciated!

This really hit home for me, as I can 100% relate with James. I’ve found the continuous job churn as a freelancer tends to create barriers when making friends at work. During my six years of self-employment I’ve struggled to have any work friendships endure past the contract term. While in comparison, to this day I’m still friends with team members from one of my first full-time jobs.

As a freelancer you tend to get used to constant change — it’s one of the things that I both love and hate about being on contract. The constant change keeps me on my toes, and ensures that I’m always being presented with new challenges. But on the flip side that constant change also means I’m continually jumping from job to job.

For most people starting a new job, while exciting, can be equally stressful. You have to continually walk into an office where everything is new — the people, the processes, the food, your desk, the commute, and everything else that comes along with a fresh start. Now imagine doing that over, and over again — that’s the life of a freelancer!

Is this all to blame on freelancing? Certainly not! This would be ignoring all the complexities that go into making lasting friendships. For example that full-time job I mentioned was back when I was in my twenties, and free time was in abundance, and making new friends seemed easier. Where as now I’m in my thirties, free time is sparse, and my number one priority is my family.

All this aside I can’t deny there are certain ingredients with the freelance life that have contributed to my shrunken circle of work friends. It’s well known that proximity, and repeated unplanned interactions are two key conditions when it comes to making new friends. Even when contracts are on-site, and I get ample exposure to these conditions, I still find it difficult to make connections that endure past the work term. Here’s a few of the challenges I’ve faced while working on contract:

• As a contractor your time at a company is limited, and because your co-workers know this I find they will sometimes be more hesitant in taking the time to get to know you. To be honest this goes both ways, and It’s something I’m working on from my end.
• Everyone loves to complain about their job to fellow co-workers. I feel like it’s a rite of passage when you’re full-time. If you’re not full-time you shouldn’t be complaining! This is not your company after all! It usually takes a while, or sometimes not at all, before a team confides in me enough to get involved in these company rants.
• There are just some conversations you’ll always be on the outs with in my experience. For example benefits, bonuses, vacation days, promotions, and end of year reviews are just some of the conversation topics that are more difficult to be welcomed into. Even when welcomed, I’ve found it’s not the same as you’re not personally impacted by the outcome of these topics, while your co-worker usually is.

I can only guess at where some of these social situations stem from, but I think it comes from a “we’re in this together” feeling that you get when you’re working with a full-time coworkers. Where as a contractor you have to jump through a few more hoops before being welcomed into the group.

In addition to the above I’ve also encountered something I can only describe as the “just a contractor” feeling. This feeling usually occurs when the fact that I’m not a permanent employee becomes very evident. This might be as simple as being left out of work related events, and conversations, or excluded from an “employees” only meeting.

One of my favourite “just a contractor” moments had to be when a company I was working for failed to inform me that they were moving offices over the weekend. So when I showed up Monday the office was empty, and I eventually found out they’d moved across the city!

I should mention that I’m not advocating for contractors to be entitled to all the same perks that full-time employees rightfully enjoy. These are merely examples of social challenges I’ve encountered as a freelancer over the years. Thankfully that last scenario is the rarity, and the majority of the companies have done their best to make me feel like part of the team. By no coincidence, these are usually the places where people are most welcoming, and as a result are the most enjoyable to work with.

So why share all this? Firstly I’m hoping to open a dialogue with others, and have them share their experiences as well. Just like James motivated me to share my story with his tweet I’m hoping I can do the same. Lastly, if you find yourself working with a freelancer on your team don’t be afraid to invite them out on the next coffee run — I’m sure they’d appreciate it!

A small note for any of you thinking of making the jump to freelance. Please don’t take this as a negative take on the freelance life. I love my life as a freelancer, and I honestly have no regrets about quitting my full-time job way back in the summer of 2012. There will always be pros, and cons when it comes to any decision, but in the case of freelancing this has probably been my only major grievance.

For more React, Redux, and JavaScript reading follow me on Medium or Twitter.

🎄The 12 Days of Reactmas 🎄

Tis the season of giving — so starting December 1st, I will be releasing 12 snack size React posts over the month of December! Each post will cover a topic like HOCs, renderProps, unit tests, and more!

🎄 Ryan Johnson 🎄 on Twitter

Tis the season for giving - over the next month I'll be doing my damndest to post 12 snack size React posts covering various topics. Like RenderProps, HOCs, hooks, and much more. First one drops tomorrow 🎄#12DaysOfReactmas🎄

🎄 Ryan Johnson 🎄 on Twitter

A small preview for tomorrow - will have code demo of the <ScrollHelper /> component that was built for this nice lil scrolling Santa 🎅 #12DaysOfReactmas #reactjs #React https://t.co/bubtg4GjzL

🎄 Ryan Johnson 🎄 on Twitter

On the first day of Reactmas I give you a <ScrollHelper /> component using the render props pattern. Help Santa by scrolling him all the way to the North Pole! Tip: On mobile? Open Preview View in new window #12DaysOfReactmas #React #reactjs https://t.co/mp5z0PxEwi

🎄 Ryan Johnson 🎄 on Twitter

On the second day of Reactmas I give you <ResponsiveBackgroundImage />. The srcSet attribute is great, but only works with image elements. With this component use srcSet with your #CSS background-images. #12DaysOfReactmas #reactjs https://t.co/OYxExiDmoL

🎄 Ryan Johnson 🎄 on Twitter

On the 3rd day of Reactmas I give you a configurable <ActivityMonitor /> component. Easily monitor events like click, mousemove, keypress, and then trigger state changes based on activity. #12DaysOfReactmas #reactjs #javascript #WebDeveloper #Rudolph https://t.co/wYX273oFSe

🎄 Ryan Johnson 🎄 on Twitter

On the 4th day of Reactmas I give you a demo leveraging <React.Fragment/>. Easily add a click blocker to a slide in navigation component, that can sit outside the bounding box of the component. #12DaysOfReactmas #javascript #reactjs https://t.co/GKJnwcTxhk

🎄 Ryan Johnson 🎄 on Twitter

On the 5th Day of Reactmas I'm sick as a dog and have no time to create anything new. Instead I want to share with you my localization library for React that optionally works with Redux out of the box! #12DaysOfReactmas #reactjs #redux #javascript https://t.co/Xb1RqKMilb

🎄 Ryan Johnson 🎄 on Twitter

On the 6th Day of Reactmas I give you a <StoreProvider/> component. Use reducers, actions just like #redux, but built on React's Context API #12DaysOfReactmas #reactjs #redux https://t.co/viuPMiY1va

🎄 Ryan Johnson 🎄 on Twitter

On the 7th Day of Reactmas I give you a withStore HOC that works with <StoreProvider /> from Day 6. Easily access your store state, and dispatch actions from any component. #reactjs #redux #12DaysOfReactmas #javascript https://t.co/sD1oxgCPSo

🎄 Ryan Johnson 🎄 on Twitter

On the 8th Day of Reactmas I'm releasing my React for Beginners course for FREE to 8 lucky people. Please use the link below or the coupon code REACTMAS. #12DaysOfReactmas #reactjs #javascript https://t.co/nhRtI6tvFR

After months of writing, recording, and editing I have finally published my first online course — React for Beginners: Build and app, and learn the fundamentals.

The course is currently available on the following platforms:

About the Course

A lot of React newcomers tend to get hung up on external dependencies like webpack, and redux. While tools like this are great they tend to add additional complexity when starting out.

In my lessons I will be avoiding all the distractions, and sticking to React fundamentals, and guiding you through the creation of your first app.

The course is split into three main categories Fundamentals, Building an app, and How React works.

Fundamentals will cover things like Elements, Components, and JSX. After that in Building an app we’ll jump right into creating a fully functional Dad joke search engine. Finally in How it works will take a look under the hood and explore how React handles rendering updates to the DOM.

After taking this course, you’ll have a solid foundation in the fundamentals of React, and should be confident enough to move onto more advanced topics, which I hope to cover in future courses.

If you have enjoyed the course please help by spreading the word! Please feel free to send any questions or feedback related to the course my way.

React for Beginners on Skillshare

React for Beginners on Udemy

Want to learn React? Check out my new course React for Beginners: Build and app, and learn the fundamentals.

I’m happy to announce the latest release of react-localize-redux. New features, new docs, new logo, and now works without Redux by default.

Want to get straight to it? Github /Official Docs

No Redux, No problem!

This latest release is built on React’s Context, and will now work without Redux by default. All you need to do is wrap your application in LocalizeProvider to get started.

We still ❤️ Redux

Redux support hasn’t gone anywhere — It’s in the name after all! So your app is already using redux? No problem, as react-localize-redux supports Redux out of the box.

Insert translations with <Translate /> component

The Translate component is how you access your translations from your components, and it can be used in a variety of ways.

Include inline default translations

With the Translate component you can include an inline translation for the default language by passing as children to the component.

Use withLocalize to consume LocalizeContext

Under the hood react-localize-redux uses React.createContext to createLocalizeContext, which holds the actions and properties needed to manage your translations. It would be tedious to explicitly wrap each component in LocalizeContext.Consumer, which is where the withLocalize higher-order-component helps.

Manage missing translations

By default any components with a missing translation will render a default missing translation message. This can be overridden by setting the onMissingTranslation initialize option.

You can also override this setting for a specific translation.

Want to learn more?

Make sure to check out the official docs, which includes full details on these additional features plus more.

• Dynamic translations
• HTML translations
• Formatting translations
• Can I use Reactive Native?

More where this came from

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

Want to learn React? Check out my new course React for Beginners: Build and app, and learn the fundamentals.

With the latest release of React the Context API has finally become a first class citizen. I have just started working with it, and so far it’s been a breeze to work with, but with one small caveat— unit tests.

Beyond an official PR in enyzme to add support for the new Context API, which at the time of this writing is still in development, I haven’t been able to find many good examples of unit testing components using context. In the meantime I’ve found the following solution worked pretty well for my scenarios.

NOTE: I’m using jest and enzyme, but I’m sure the mocking technique being used can be applied to other testing solutions. For full working example see react-localize-redux v3 branch

In this example I’m creating a new context namedLocalizeContext that will be responsible for passing localization info to any components that wish to consume it.

Now let’s create a simple LanguageSelector component that consumes the LocalizeContext. By adding LocalizeContext.Consumer to our component we are able to retrieve languages and activeLanguage from LocalizeContext.Provider.

Now we have a component that renders a link for each supported language, and adds styling for the active language link. I want to add unit tests to the LanguageSelector component, but before doing that I need a way to handle the LocalizeContext.Consumer component in our tests.

For this we’re going to leverage jest’s awesome mocking capabilities — more specifically the jest.doMock method. With this we can create a utility method that is passed the required context, and returns a version of LanguageSelector with a mocked consumer.

That’s it! Now when we run each test we can pass in mock context data to drive the test. This was a very simple example, but you can also view a full working example at react-localize-redux v3 branch.

For more React, Redux, and JavaScript reading follow me on Medium or Twitter.

Want to learn React? Check out my new course React for Beginners: Build and app, and learn the fundamentals.

Have you ever had a slice of state from one reducer that you needed access to in another reducer? If you’re using Redux’s combineReducers out of the box then you may be stuck, or you could use reduce-reducers, but that may be overkill for your needs.

Instead why not write your own combine reducers?

It’s easy to forget that reducer’s are just a functions with the following format (previousState, action) => newState, and there’s no reason you can’t write your own version of combineReducers to handle this scenario. The following is a pattern I use to access state from different slices in my reducer.

For example if we were building an app that deals with localization we might have the following state shape:

In the above state languages is an array of languages the app supports, while translations is an object where each key’s value is an array with a translation for each supported language. If we were using combineReducers to assemble this state it would look something like this…

The above works fine, but what happens if we need access to data from languages from the translations reducer? If you’re using combineReducers you will only have access to your reducer’s state. Instead you can use the following pattern to create a custom reducer function that combines your reducers, and passes the required data across reducers.

Although this pattern works well enough, I would not abuse it. If you find you’re having to frequently pass state across multiple reducers it may be a sign that your state shape needs work. Either way remember reducers are just functions — don’t be afraid to experiment!

For more React, Redux, and JavaScript reading follow me on Medium or Twitter.

Passing state between reducers in Redux was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m a developer, and I love what I do!

I have been doing this for 10+ years now, and a lot of things have changed since I dipped my toes into programming — Macromedia Flash anyone? Yep, programming for me started with stringing together MovieClips with sexy code like goToAndPlay(10)… let’s pour one out for ActionScript folks.🍾🍾

From there it’s been a freight train of new things year after year … from jQuery, Facebook Apps 🤢, HTML5, Backbone, Angular, and React. Let’s not forget a brief foray into Ruby on Rails, good ol’ PHP, Node.js, and the endless string of build tools — looking at you Grunt/Gulp/Webpack. I could go on and on, which brings me to the primary point of this article…

Being a developer is awesome, but I often feel the pressure of “keeping up” overwhelming!

“keeping up” with the latest and greatest

When you’re a developer it’s like signing a contract that says I will never be done learning. I think continued learning is an integral part to any good developer’s growth, but things change at such a furious pace that this can be draining. Even more stress is added when you consider that your valuable time may be spent learning something that could be obsolete in six months.

For me the pressure to keep up with the latest and greatest becomes daunting at times. I have often thought, if I’m ever lucky enough to have extended time off work would I truly be able to unplug during that time? Sure, my core skills would remain intact, but upon my return I could find that React is old news, and AwesomeSauceJS is the new treat of the week — looks like all my previous expertise is out the window. Ok ok… that may be an exaggeration, but this doesn’t prevent these thoughts from crossing my mind when I take time off.

“keeping up” with others

Have you ever looked at someone’s Instagram feed, and thought damn that person’s life looks amazing. In reality we’re only getting a glimpse of a polished version of that person’s life with all the “bad” filtered out. I feel the same goes when you’re a developer looking through your Twitter, GitHub, or some other social platform — you can’t help but constantly compare yourself to your peers.

• How in the hell does this person have 100k followers? Shit! Looks like I need to message everyone in Canada asking for a follow.
• What!! wobblybits.js just got another 500 ⭐️’s on Github? My open source projects must be suck!
• Holy crap that developer just spoke at 20 conferences last month! I can’t even put together a damn lunch and learn for work.
• Wow! @megadevloper2000 just published a new library, released a new podcast, and managed to write a book on teaching your dog to program.

Obviously these are exaggerations, but my primary point is an hour on Twitter can easily have you questioning the work you’re doing or not doing. Can this same content be used for motivation? For sure, but at the same time, like that perfect Instagram feed, it can have you unfairly weighing your success based on what others are sharing and doing.

In closing

At the end of the day if this is the worst part about being a developer then we are sitting pretty. I feel privileged to be part of this community, and look forward to many more years of growth in the industry. If you happen to relate to any of this I find the following reminders help when I’m feeling overwhelmed:

• If you have time to learn something new that’s great! Make sure to choose something that excites you, and you’re not picking it up because of outside pressure.
• If you’re not in the right mindset, or don’t have the time to learn something new — don’t force it! This will just create more stress on your end, and most likely result in a negative learning experience.
• Be your own judge and jury when it comes to measuring your success, and don’t let comparing your accomplishments to other’s diminish your own.
• People on Twitter pissing you off? That OS project not motivating you anymore? — Don’t be afraid to unplug, even if it’s just for the night it can make all the difference.

For more React, Redux, and JavaScript reading follow me on Medium or Twitter.

One developer just trying to keep up was originally published in Statuscode on Medium, where people are continuing the conversation by highlighting and responding to this story.

UPDATE: Since this article was published a lot has changed. The majority of the issues I had with TypeScript have been resolved, and it appears that TypeScript has pulled ahead as the tool of choice for JS type checking. I’m even moving my own projects from Flow to TypeScript.

I must admit when I first tried TypeScript on a project I was skeptical. After all this is JavaScript we’re talking about — what the hell do I need types for? But after having used it on a large team project over the last eight months I’ve really come to depend on the stability types bring to a shared codebase.

But here’s the thing…that type safety came with some baggage as well. Here are some items I found to be a pain point with TypeScript:

• All your files use the .ts extension instead of .js — it might just be me but this always felt dirty.
• No easy opt-in option if you want to slowly introduce TypeScript into an existing project — felt like all or nothing. (Update: See Type-Checking JavaScript Files with — checkJs for a way to migrate an existing project to TypeScript)
• Tooling overhead —you may find that you need to add additional dependencies so your tooling can handle .ts files. (e.g. unit tests)

These are some of the sticking points that led me to give Flow a try, and although it’s still early, I’m liking what I see so far, and here’s why…

Your files are still JavaScript

This may seem like a small thing, but at the end of the day you get to keep that .js extension, and all your files remain JavaScript. You only need ensure that Flow types are stripped from your files during your build. If you happen to be using babel this is as simple as adding babel-preset-flow to your .babelrc file.

Opting in is easy

Want to add Flow to an existing project, but want to do it in small chunks? No problem, all you need to do is add // @flow to the files you wish to use Flow in — that’s it!

Less strict with dependency type definitions

This could have been specific to my project’s configuration, but TypeScript would always complain about third-party libraries missing type definitions. This would then involve checking if a type file exists, and then installing it. This was extra painful when trying to convert an existing project with many dependencies, as you have to install these type definitions one by one.

Where I found Flow would simply ignore those dependencies that were missing type definitions. And if you wanted to add definitions it was super easy with flow-typed, which will automatically installs definitions based on your package.json. An added bonus — if a definition for one of your dependencies doesn’t exist inflow-typed it automatically stubs out a file definition for you.

Focused on static type checking only

Flow is a static type checker for your JavaScript code — that’s it. Not a transpiler, not a superset of JavaScript, just a type checker. It does one thing, and it does it well.

Great support

When I hit a few roadblocks during development I reached out directly to the Flow twitter account, and I was answered directly by Caleb Meredith part of the Flow team. This help was invaluable, and it was such a welcome surprise considering how busy these guys must be.

Want to give Flow a go?

I’m still new to Flow, but I have enjoyed working with it thus far, and hope to continue using it in future projects. If you want to check it out for yourself I’ve included some resources that I found helpful along the way:

• Official Flow Docs
• flow-typed —A central repository for Flow library definitions
• graphql & redux-form — These projects source files are a great resource as they both use Flow.
• Authoring and publishing JavaScript modules with Flow
• Online Flow editor

For more React, Redux, and JavaScript reading follow me on Medium or Twitter.

Why I gave Flow a shot after TypeScript was originally published in Netscape on Medium, where people are continuing the conversation by highlighting and responding to this story.

Simplified usage, selector optimizations, plus more!

NOTE: This article is out of date as v 3.0 has been released, and now works without Redux by default. Please see the official docs or the official release announcement for details.

The original version of react-localize-redux was created based on some work I did on a client project, and although it worked fairly well I knew there was room for improvement. With v2 I was able to realize many of these improvements.

React Localize Redux is a collection of helpers for managing localized content in your React/Redux application. For full details on Installation, Usage, etc.. visit the official github page or read Dead simple localization for your React components.

Simplify that 💩…

No more global vs local translations

In v1 there was the concept of local vs global translations, which resulted in additional complexity. In v2 all translations are one and the same, and any component can access a translation as soon as it’s added.

Reduce repetition in translation data

In v1 translation data looked something like the example below — where each supported locale repeated the same keys over and over 😔.

{
  "en": {
    "greeting": "Hello",
    "farwell": "Goodbye"
  },
  "fr": {
    "greeting": "Bonjour",
    "farwell": "Au revoir"
  }
}

In v2 I removed the redundancy by having one set of keys, and each key’s value having an array of translations like the below example 😃.

{
  "greeting": ["Hello", "Bonjour"],
  "farwell": ["Goodbye", "Au revoir"]
}

Support for nested translation data

In v2 you now have more flexibility with formatting your translation data. Now you can nest your data, which can help with organization and avoid naming collisions.

{
  "welcome": {
    "greeting": ["Hello ${ name }!", "Bonjour ${ name }!"]
  },
  "info": {
    "greeting": ["Hello", "Bonjour"]
  }
}

Which you would then access like so in your component…

<h1>{ translate('welcome.greeting', { name: 'Testy McTest' }) }</h1>
<h1>{ translate('info.greeting') }</h1>

New selectors for components using connect

In v1 the only way to get access to the translate and currentLanguage prop was to wrap your component with localize. For components that are already connected you can now use the getTranslate and getActiveLanguage selectors instead.

In v1 you could end up with a scenario like this… 😔

const Greeting = ({ translate, currentLanguage, onClick }) => (
  <div>
    <h1>{ translate('greeting') }</h1>
    <button onClick={ onClick }>{ translate('farwell') }</button>
  </div>
);

const mapStateToProps = state => ({ onClick: clickHandler });

export default connect(mapStateToProps)(localize()(Greeting));

In v2 this becomes… 😃

const Greeting = ({ translate, currentLanguage, onClick }) => (
  <div>
    <h1>{ translate('greeting') }</h1>
    <button onClick={ onClick }>{ translate('farwell') }</button>
  </div>
);

const mapStateToProps = state => ({ 
  translate: getTranslate(state),
  currentLanguage: getActiveLanguage(state).code,
  onClick: clickHandler
});

export default connect(mapStateToProps)(Greeting);

NOTE: A simplified version of the localize method is still available in v2, and is perfectly fine to use for components not already using connect.

Migrating from v1?

The change to v2 did result in some breaking changes with v1, but I’ve created a migration guide that will hopefully help out with anyone making the switch.

Conclusion

Thanks for your support and I hope you enjoy v2. As always feel free to send any feedback my way.

💥 react-localize-redux v2 💥 was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Want to learn React? Check out my new course React for Beginners: Build and app, and learn the fundamentals.

If you’re using Redux in your React app you’re likely using react-redux to connect your components to your state. The connect method is a tricky sum bitch— although it has a very simple API there’s a lot of magic happening under the hood. It’s very easy, especially when first learning Redux, to just start connecting things without much thought on what’s actually happening. One of the easiest snafus to make is to connect your component at the top of the render tree.

What the hell does that mean exactly? I’m glad you asked — the following diagram demonstrates this scenario. In this example the <Page> component is connected at the top of the render tree.

Why does this suck?

• You change the profile image the ENTIRE <Page> renders
• You remove a feed from the list the ENTIRE <Page> renders
• You add an image the ENTIRE <Page> renders

Instead of connecting to the <Page> component let’s connect <Profile>, <Feed>, and <Images> directly to their slice of state. Here’s an updated version of the same diagram to demonstrate:

Why is this better?

• Changing the profile image only <Profile> renders
• Removing a feed from the list only <Feed> renders
• Adding an image only <Images> renders
• Less renders === 🌈🌈🦄🦄

Remember when you connect your component you are telling React to render the component anytime any of the connected props changes. By having each component do it’s own connect we avoid the unnecessary renders that were happening when we connected at the top of the render tree.

Wrapping up

I recommend anyone new to connect takes the time to fully understand what is going on when you connect a Component. I myself was guilty of doing cut & paste from tutorials at the beginning, and taking many missteps along the way.

Bonus Round

1. If you are doing Redux I recommend taking a look at reselect. This allows you to create smart getters for Redux called selectors. A selector is not recomputed unless one of its arguments change, which will help avoid unnecessary renders.
2. Good ol’ RTFM — read the react-redux docs in full. It turns out that the connect method has plenty of options beyond passing mapStateToProps and mapDispatchToProps, including a renderCountProp you can add to your component to track render count.

Ryan Johnson on Twitter

Pass connect "renderCountProp" option to debug unnecessary renders - adds prop to connected component that tracks number of renders. 🔥🔥 https://t.co/zLDvjYm5nE

For more React, Redux, and JavaScript reading follow me on Medium or Twitter.

Quick Redux tips for connecting your React components was originally published in DailyJS on Medium, where people are continuing the conversation by highlighting and responding to this story.