Skip to content
Author Micah Cambre

generational divides

Older: That’s crazy
Younger: That’s wild

Older: Completely or Absolutely
Younger: ? or 100%

Older: I kinda don’t…
Younger: I low-key don’t…

Older: Know what I mean?
Younger: IYKYK

Older: That’s weird
Younger: That’s sus

Older: I got your back, my friend
Younger: I got you, fam

Older: You’re too much
Younger: You’re so extra

Older: You’re the best!
Younger: You’re the GOAT

just thrown away like that

I had to look it up just now because I don’t remember when I started using it.

It was around May of 2009. I don’t even think it was possible to use you browser to access it, either. It was before iOS had an app.

Twitter didn’t even own it yet!

This was two years after I started using Twitter in March of 2007; Twitter permitted for us to sign up at SXSW that year so I was an early user even though I didn’t really understand its utility and it was still finding its place.

Tweetdeck is how I primarily interacted with Twitter all this time. It’s consistent. It provided near real-time updates without me refreshing. It’s my go to, to see how the public is reacting.

Then, this past Sunday, it was yanked away from me and replaced by the new version. A version that’s going to be locked down behind a paywall after the end of July. And this new version just doesn’t compare or stand a chance.

Sure, I have other ways to figure all of this out. But Tweetdeck was there for me through a long span of my adulthood.

I could see all kinds of people confirming that I just felt an earthquake. I got to know smaller personalities who weren’t well-known. I also could see what celebrities were thinking. So many pointless brands hawking to get my attention.

It was always there. I learned a lot. I was always entertained.

If it’s locked up and thrown away from me, so be it. I won’t miss what it is now.

EDIT July 9 – They are allowing the old version to be used again, but I cam only assume it’ll still be hidden behind a paywall after the end of the month.

relearn using dishwashers


Detergent packs are kinda wishy-washy (Dishwashers Explained)

I’m writing this post to clear off some of the dust from this site. I’m linking to a YouTube video that goes deeply into using dishwashers and how so many of us have forgotten how to actually use dishwashers well. In fact, we really should stop hand washing too often to conserve water and reduce our bills since dishwashers are so efficient AND effective with less use of everything.

Four steps to effective dishwashing:

  1. Turn on the facet water and let it get as hot as it can. The dishwasher needs this hot water from beginning to end.
  2. Fill the pre-wash cup with detergent. Using a tablet? Drop a tablet into the dishwasher’s bottom. I’m using plain Finish tablets for this
  3. Fill the main wash cup with detergent. This is usually the one with a door that you lock into place until mid way through the cycle. This is where the fancier tablets can be used, but Finish is also just fine
  4. Check your rinse aid level. Do you see any in there? Fill it up, it adds a pop to the cleaning!

And seriously, if you do all four of these steps, you should be seeing a better dishwashing result every time! The biggest benefit you can take away is the pre rinse with both hot water and soap. If you get this right, the rest of the cycles do their job great.

Now, let’s see if this syndicated a nice little Twitter link into a Tweet. I haven’t tested this feature in a while!

custom roms rock

I am loving using an open source android custom rom! I can pick and choose who gets what and I’m in control of everything. This is a game changer. This deserves a blog post…

This is a test for using quill on this blog

RSVPed Attending IndieWebCamp East

IndieWebCamp East 2020 is an online gathering for independent web creators of all kinds, from graphic artists, to designers, UX engineers, coders, hackers, to share ideas, actively work on creating for their own personal websites, and build upon each others creations.

ghost peppers ouch

Lesson learned: ghost peppers affect you the whole way through the body! One accidental ingestion and 12 hours of intermittent heat ???

react’s separation of concerns

It’s funny how patterns and styles get recycled. We’ve seen clothing styles of the 60’s get reintroduced and reused decades later. The TV show Mad Men brought back mid century modern style into the 2000s. And we’ve seen it happen with coding patterns as well.

React Components

One of the first React things I learned is how to create React Components, Capital-C.

export default function NavButton() {
		<button type="button">Switch Step</button>

To use this button, just import it into other files and apply it in the JSX. Straightforward.

Props == HTML Attributes

Buttons usually need to do things, so let’s give this some interactivity.

function NavButton(props) {
	const { transitionCallback, isDisabled } = props

	const handleClick = () => {

			Switch Step

2000s me looked at this increasingly used React pattern curiously, because I see onClick={handleClick} attached to the button element. For so many years, often from jQuery or Javascript, I avoided applying event handlers to elements. But here React made that a pattern and my mind goes back in time.

My concerns are separate

I spent the 2000s and into the 2010s learning about, what I eventually started reading from industry folks and books, a computer science term called Separation of Concerns. The idea makes sense on the front-end for many reasons and I became fairly dogmatic about it.

With Separation of Concerns, these three concepts stand on their own:

  • structure (HTML)
  • presentation (CSS)
  • behavior (JS)

By the middle of the 2010s, I wasn’t mixing JS and CSS into HTML, CSS into JS or HTML into JS. We keep them separate, .html, .css, and .js.

By contrast and in practice, however, having worked with WordPress all that time, it was often a losing battle to decouple these languages, quick jQuery or CSS fixes were little inline sprinkles here and there.

function ratio_calculator() {
    $html = '<style>
	.form-inline .form-group { display:block; margin-bottom: 10px}
<form id="form" name="form" method="GET" action="#" role="form" class="form-inline">
	<div class="form-group">	
		<label for="RT3" class="t3">RT3</label>
		<input class="form-control" type="text" name="RT3" id="RT3">
    <input type="button" class="btn btn-primary" name="button" id="Submit" value="Get Ratio">
<div id="ratio" style="color:blue;font-weight:bold;font-size:120%"></div>';
return $html;

Yuck! I had to grit my teeth and move on.

Then came modern JS frameworks, cemented by React, slowly blowing this concept up. React’s raw JSX syntax requires to cross the decoupling line by adding HTML-like attributes called props containing Javascript and often CSS. A different and controversial method called CSS-in-JS is not only accepted but widely adopted by many React developers. And then there’s the other CSS direction of using utility first libraries like Tailwinds polluting HTML classes, but don’t get me started on that concept!

Separation of Concerns Remixed

In this new paradigm of component-first development, the abstraction for separation of concerns takes on a different look. The separation of concerns is loosely defined within the components themselves. Let’s take a look at what this means.

Here’s my first iteration of the navigation button control component to go from the initial state to the timer state.

function NavButton(props) {
	const { transitionCallback, isDisabled } = props

	const handleClick = () => {

			style={{padding:'1rem', backgroundColor:'white'}}
			<span className="visuallyhidden">Switch Step</span>

This code shows a clear mix of all three languages within a Javascript function, with an HTML-like syntax inside of a Javascript return statement, inline CSS in a button element, and an inline onClick event handler calling a function.

Before I started learning how to make websites, the source code of the web documents used similar syntax that kind of looked like the above.

	<script type="javascript">
		function handleClick() { 
			var transitionCallback = props;

When I first saw React’s syntax, you can imagine how alarmed I was by its seemingly reversion back to the 1990s styling of code. My mental model is so conditioned that this bothered me for a long time, still does to some degree.

Two what end?

As I see modern libraries continue these practices, it appears the pattern of everything inside of JS will continue into the foreseeable future, one way or another. Discussions around native Web Components in the document brings a more dogmatic potential back, but not in its current iteration.

I’m always excited for the future, but I think there will always be a part of me looking of ways to scale back the abstractions and packages needed to build the modern web. Part of that will be my outdated mental model for separation of concerns. Let’s hope browser makers can find better ways to manipulate the DOM and CSSOM without breaking the clients and mixing our concerns!

react reflections in 2020

A few years ago, realizing that both Javascript and React are probably the future of my career in web development, I slowly started reading more and casually learning what I could. I’ve come from such a front-of-the-front-end mindset, bordering on being a developer envying to be a designer, that learning Javscript has taken years for me.

Now that I have both training experience and real-world application of React, I want to jot down various things that I’ve learned as well as still struggle with. (It’ll also be entertaining to re-read this in a while to see how primitive my likes and dislikes are!)

Logical Operators, aka &&

I think this is one of my favorite ways to render components in React. It’s concise and very readable.

const [ activeElement, setActiveElement ] = useState(false);

return (
    {activeElement && <Accordion onClick={handleClick} />}

Is activeElement true? Sweet, let’s render that Accordion component. Easy to understand, easy to remember.

Form components

One of the more confusing parts of React is Controlled Components vs Uncontrolled Components. Most of the components I’ve written are uncontrolled because of the amount of things I have to do with them. In fact, I find it difficult to justify writing controlled components because doing this misses things for me.

  onClick={() => setSelectedField("first-name")}
  onKeyDown={e => handleKeyDown(e, "first-name")}
  onChange={e => setData({, first_name: })}

See all of these event handlers? Whether it’s validation or another key dependent event, even a custom click handler for custom action, controlled components seem too restricted in what they provide. The biggest drawback for uncontrolled components, unfortunately, is taking the power away from the form’s global handlers like onSubmit. You have to handle this event in the click handler or keydown handler to be able to send or receive the proper data for the element.

Functional Components + Hooks > Class Components

Keeping a mindset of using state in a hook, this allows a few quite appealing benefits.

  • Avoids prop drilling – Whether it’s encapsulating state with useState() or accessing it more globally with useReducer(), state doesn’t have to flow through multiple components to be manipulated as props
  • Less code – It feels and looks better to write functional components with hooks like useState().
  • What lifecycle methods? – I didn’t have to spend a lot of time with a method like ComponentDidMount (among the rest) before I started using useEffect() for most methods to work with data. The more I use it, the more I like its simplicity of helping data flow.

I much prefer updating state with useState() instead of setState(), despite doing similar things. Maybe this is just my personal optics?

Avoiding Prop Drilling

It took me some time to really get the concept of state and props, despite the seemingly simple ways to use them. One of the least favorite things I have to do is find where data starts and how it flows. When you have a microapp that declares a lot of state at top, somehow the the child components need to use a lot of that state and it could pass several levels down before it gets to the correct component for updating as state. Here’s a small example.

function Profile() {
  const [name, setName] = React.useState("")
  return <Form name={name} setName={setName} />

function Form({name, setName}) {
  const handleChange = e => {
    // Do other things here...

  return (
    <div class="form-component">
        onChange={() => handleChange(e)}
      <button type="button" onClick={() => setName(name)}>Update

You get the idea even if this is imperfect. Essentially, we’re giving this form two ways to update: first through the normal onChange method which updates state, which can then be submitted normally, and second using a normal button that sets the name that was already updated by the input field. While this is fairly simple, as an app grows, such as multiple fieldsets of form fields or possibilities of what needs to be stored, updated, created, and so on, props need to be passed down to the various components that are especially written for the form.

If anything, using hooks has made my functions pretty single purposed in what they do to avoid complexity. Maybe it’s more verbose in some ways but it’s ultimately more readable.

Manipulating fetched data

JSON data is still one of my bigger challenges as I learn React and modern Javascript at broad. It can be tedious trying to figure out how to get data from an API to the component in the most efficient way.

Let’s fetch some data.

function PeopleProfiles() {
  const [ profiles, setProfiles ] = useState([])
  const [ activeProfile, setActiveProfile ] = useState(undefined)

  const fetchData = async () => {
    const results = await fetch("")
      .then(data => setProfiles(data))
      .catch(err => setErrors(err))
    const activePorfileExists = => activeProfile ===

    if (!activeProfileExists) setActiveProfile([0].name)
    return results

  useEffect(() => {
      .then(results => setActiveProfile([0].name))
  }, []);

Note: this probably won’t work but it’s an okay example for this purpose

Once the data is fetched from the API, we add the data to the profiles state using setProfiles. From there, we can replace, update, create and delete as needed. For visual purposes, there’s an active profile state that will choose the first object if no other profiles are in the active state.

All of this is performed when the component mounts inside of useEffect(). You can see that we’re only calling it once

Because we’re calling the data inside of useEffect() with an empty array as the second argument, this only runs when the component mounts the first time. Any time I tried to add state to the second argument, I kept getting a 429 error where it makes too many calls. I needed to update the state dynamically, which would be equivalent to componentDidUpdate.

I found a better way to update the view with new data is to fetch the data outside of useEffect() and call this function from the component or method that needs the view to update and show the updated data.

Let’s say, within the profile component, I have an input that allows me to update the data. In an ideal scenario, API data fetches are encapsulated into a global file. This app isn’t big enough for that so I’m passing fetchData down to the child component in order to update the view with new data.

  return (
        className="Form Form--LovedOnesSpecialDates"
        <div className="Form--LovedOnesSpecialDates__wrapper">
          { =>

I think this is one of the biggest problem areas with using React. Best practices for fetching and manipulating data have changed a few times as the language has updated itself. I’ve dived deep into React after ES6 was a big part of React via babel and webpack. I also didn’t have to spend a lot of time to understand React’s class component structure. There was just Javascript

But still, there’s a lot of legacy and historical knowledge of plain Javascript that is needed to really help understand the nuances of what React is doing whether it’s mapping through an array or knowing how to pass data from the API to the application’s state.

Conditional loading

Related to logical operators above, React’s conditional loading is not always obvious but interesting nonetheless.

const LovedOne = ({
  id, // number
  activeProfile, // string that's actual a number
  showAddProfile // boolean
}) => {
  return (
      className={`Profile${parseInt(activeProfile) === id ? " profile-active" : ""}`}
      onKeyDown={!showAddProfile ? handleProfileSwitcher : undefined}
      onClick={!showAddProfile ? handleProfileSwitcher : undefined}
      // Add code here

It took me too long to find these patterns for render props.

For some reason, I could not pass down a number in the render prop called activeProfile. The console kept complaining so I had to turn the number into a string to get it into this component. So how do I actually use it?

The first attribute is the using a ternary function to set a specific class. The part that wasn’t obvious was matching the id to the activeProfile, which weren’t matching since it’s a string and number. I guess a using loose equality with a == might have solved it, but some linters don’t like it in some situations so I always default to strict equality ===. Either way, I had to turn the string into a number to be able to evaluate if they equal each other.

The second pattern was also a ternary that uses undefined to prevent onKeyDown or onClick from rendering in the markup. This was necessary because at larger viewport widths, these article elements don’t need to be used to help switch the active profile.

The rest

I think I’ll never stop cringing at PascalCase component names both in markup and stylesheets or using className instead of class among other things. I’m still caught in between writing classical components, HTML, CSS and JS vs how React based components. Let’s see what another year of this does!

Good riddance, #chrome. Hello #brave. But forever. I can’t find a reason to install Chrome on any new computer anymore and have removed it from my existing devices.