Back in the day, Laravel 6 came out-of-the-box with an `app.js` file that auto-wired up Vue components. After including `app.js` in your root Blade template, you could use Vue's web component syntax _anywhere_ to drop Vue components on your Blade templates, and they would resolve to the Vue component. Here's the relevant snippet from Laravel 6 that made the magic happen:

```js title="https://github.com/laravel/framework/blob/6.x/src/Illuminate/Foundation/Console/Presets/vue-stubs/app.js#L11-L20"
/**
 * The following block of code may be used to automatically register your
 * Vue components. It will recursively scan this directory for the Vue
 * components and automatically register them with their "basename".
 *
 * Eg. ./components/ExampleComponent.vue -> <example-component></example-component>
 */

const files = require.context('./', true, /\.vue$/i)
files.keys().map(key => Vue.component(key.split('/').pop().split('.')[0], files(key).default))
```

Using the two lines above, one could drop
`<example-component></example-component>` anywhere you wanted on the page and
achieve reactivity. This allowed you to get moving quickly without thinking too
hard about marrying JavaScript to the server-rendered parts.

While Laravel has since abandoned the above in favor of Inertia or Livewire, the auto-resolution convention is a great fit for sprinkling reactivity on older applications. So when my company decided to pull React into our 10-plus year old application, I remembered my experience with Laravel 6 and created the proof-of-concept [Inline JSX][inline-jsx] to suggest an improvement to our developer experience.

[inline-jsx]: https://github.com/dstrunk/inline-jsx

## What does this solve?

Inline JSX is meant to provide a way to add React to an existing application. A full rewrite of the application into a single-page application is off the table. The application does not have a dedicated API, so creating new endpoints just to support React is beyond the scope of the React addition. The application has a capital "V" View layer that allows for providing server side data, which can be used to hydrate the React application with initial data.

If this sounds like an application you're working on, Inline JSX may be for you!

## Before Inline JSX

Adding React to an existing application is pretty straightforward--the React documentation covers it in the ["Getting Started"][react-getting-started] section. It's fine, but filled with boilerplate. It also leaves the question "how do we hydrate data?" unanswered... do we:

[react-getting-started]: https://reactjs.org/docs/add-react-to-a-website.html#add-react-in-one-minute

1. Instantiate a global `window` object in the template and reference it after the React component mounts?
1. Make a `fetch` call within the React component after the component mounts?

For this example, let's assume a global `window` object. First, the template:

```php
<html>
  <head>
    <script src="js/react.js"></script>
    <script src="js/react-dom.js"></script>
    <script src="js/add-to-cart.js"></script>
  </head>
  <body>
    <div id="add-to-cart"></div>
    <script>
      // instantiate a global `product` that can be used to hydrate the React component.
      // Alternatively, a `fetch` could be done in the React component itself.
      window.product = <?= json_encode($this->getProduct()); ?>;

      // Create the React component
      const addToCartRoot = ReactDOM.createRoot(
        document.getElementById("add-to-cart")
      );

      // Mount the component to the `#add-to-cart` DOM node
      addToCartRoot.render(<AddToCart />);
    </script>
  </body>
</html>
```

Then, in the component:

```jsx
function AddToCart() {
    let product;

    // Instantiate the product on mount
    useState(() => {
        product = window.product
    }, [])
}
```

## After Inline JSX

Using the inline JSX approach, things become a lot easier. After adding `app.js` to your page, all of React's boilerplate is replaced with a `<web-component></web-component>` style DOM element. Instead of wondering if we should add a `window` global or `fetch` call, you add an HTML attribute containing any data needed to hydrate the React component after mount:

```php
<html>
  <body>
    
    
    <add-to-cart product="<?= json_encode($this->getProduct()); ?>"></add-to-cart>

    
    <script src="js/app.js"></script>
  </body>
</html>
```

The data passed to the component via HTML attributes can be destructured from the React component as you would normally expect:

```jsx
// `product` is an HTML attribute in the above example
function AddToCart({ product }) {
    // ...
}
```

## Caveats

This approach comes with some challenges. Some are limitations with the HTML parser, while others are architectural decisions that should be considered.

### Case insensitivity

HTML tags and attribute names are case-insensitive. This means any PascalCase component names or camelCase prop names need to be converted to kebab-case equivalents.

The Inline JSX proof-of-concept accounts for this conversion, but to hammer the point home, here is how you can expect the HTML components to be converted to JSX:

```html
<my-react-component html-attribute="hello world"></my-react-component>
```

Note the PascalCase for the React component, and the camelCase for the html attribute:

```jsx
function MyReactComponent({ htmlAttribute }) {
    // ...
}
```

### Self-closing tags

The HTML spec only allows a few specific elements to omit closing tags. For any other elements, if the closing tag is omitted, the HTML parser will think the tag was never closed. The browser will attempt to close the tag itself, and you may run into errors. For example:

```html
<example-component />
<span>hello world</span>
```

The above may be parsed like the following:

```html
<example-component>
    <span>hello world</span>
</example-component>
```

### Communicating with other components

Since each component is technically a standalone React application, communication between _different_ applications needs to be solved. Say, for example, you have a `MiniCart` component that needs to update once a user adds a product to the cart? In the `inline-jsx` repo, my solve for this was an event bus pattern:

```js
const events = {}
let eventId = 0

const publish = (event, ...args) => {
  const callback = events[event]
  if (!callback) return console.warn(`${event} not found`)

  for (let id in callback) {
    callback[id](...args)
  }
}

const subscribe = (event, callback) => {
  if (!events[event]) {
    events[event] = {}
  }

  const id = eventId++
  events[event][id] = callback

  return {
    unsubscribe: () => {
      delete events[event][id]

      if (Object.keys(events[event]).length === 0) {
        delete events[event]
      }
    }
  }
}

export default { publish, subscribe }
```

The above is the entire event bus... but for something more full-featured, feel free to reach for Redux.

Once the event bus is added, you can publish events anywhere you want to communicate to an outside component:

```jsx
import { v4 as uuid } from 'uuid'
import eventBus from '../eventBus'

function AddToCart({ product }) {
    const addToCart = (product) => (e) => {
        e.preventDefault()

        eventBus.publish('MINICART_ADD', {
            product,
            quantity: 1,
            message: {
                id: uuid(),
                type: 'success',
                title: `Product added to cart`,
                body: `${product.title} has been added to your cart.`,
            }
        })
    }

    return (
        <button onClick={addToCart(product)}>Add to Cart</button>
    )
}
```

Then, any components that need to act based on the published events just subscribe to the published event:

```jsx
import eventBus from '../eventBus'

function MiniCart() {
    const [items, setItems] = useState([])

    useEffect(() => {
        const addItemsSubscription = eventBus.subscribe('MINICART_ADD', ({ product, quantity }) => {
            const item = { ...product, quantity }
            const oldItems = [...items]
            const itemIndex = oldItems.findIndex((i) => i?.id === product.id)

            if (itemIndex < 0) {
                setItems((i) => [...i, item])
            } else {
                const updatedItem = items[itemIndex]
                updatedItem.quantity++

                setItems((i) => [...items])
            }
        })

        return () => {
            addItemsSubscription.unsubscribe()
        }
    }, [items])

    // Return an actual minicart ...
    return <></>
}
```

### Data grids

To be honest, there's not really a solve for this using the inline JSX approach. While it's easier to add simple React components to the page without having to introduce new API endpoints, hydrating a component that has the potential to have hundreds of thousands of rows begins to be a performance and memory concern from a server perspective. In this case, an API endpoint coupled with a `fetch` call would be a better approach.

## Summary

Writing this proof-of-concept was fun--I got to work on something that I'm a big fan of improving, Developer Experience (DX), and I learned more about the some of the inner workings of React's boot process. I hope people find it useful!

For a more thorough example of some use-cases of the inline JSX approach, check out the project's `index.html` page: https://github.com/dstrunk/inline-jsx/blob/main/public/index.html

Easily add React root components to your HTML templates using web component syntax.

Inline JSX for React


My career trajectory has been quite average, all things considered. I started
working in 2009 as an in-house graphic artist before quickly transitioning into
a more technical role, kicking off my career in web development. In 2015, I moved to a new company as a Magento developer, where I worked until
January 2022.

In both cases, I worked in-office. Commuting, wearing uncomfortable clothes, sitting in noisy open-office environments that distracted me, for almost thirteen years. Thirteen years!

My first brush with remote work is similar to other peoples' stories: with the pandemic. In 2020, almost overnight, I went from in-office work to remote. And I loved it so much, I decided to continue doing it.

In January of this year, I got my first remote-only job, and I plan on continuing with remote work indefinitely.

I mention my career history only to point out that there was no dedicated effort to transition to remote work. There are, however, things that I've done to set myself up for continued success with working remotely.

## Have a schedule

This is one of those obvious tips that every blog post in this vein touch on. With good reason: if you aren't diligent in sticking to a schedule, you'll slip into working later and later, ending the day earlier and earlier, and losing your coveted remote job faster than you can say "nine to five."

With regards to having a schedule, there's an important one that speaks to me personally: unplugging.

### Unplug

This may be easier said than done--I have to make a conscious effort week-by-week. When the day is done, stop working!

This is especially hard when you work on a distributed team. My team, for instance, spans multiple time zones: Pacific, Central, Eastern, and Central European. That last one throws things for a loop, eh? So product or design questions may not come through Slack until 19 or 20:00 EST, while development questions from our European friends will begin around 3:00 EST. You have to use discretion here, because it's certainly up to the culture of the company, but **if you can**, log off when _your_ day is finished.

Slack and emails are meant for **a**synchronous communication, not synchronous. Also? Slack allows you to schedule your messages ... I suggest applying liberally.

## You should have an office

... or at least a work area that affords you peace and quiet. Between standups, retrospectives, one-on-ones, pair programming sessions, and other ad-hoc meetings, I tend to be on video at least three to five times a day.[^1]  Without a dedicated area to field these calls, I would have quickly given up on remote work.

[^1]: What, you thought remote work meant not working with people?

I've been low-key setting myself up for remote work for years. By the time the pandemic rolled around, I'd already set up a dedicated office in my house with a sit-to-stand desk, multiple monitors, a comfortable chair and a nice camera. It was a pricey investment, for sure. But it ended up paying dividends--I now have a nicer office than I _ever_ had working in-office.

I'm not saying you need this same investment, but consider this, at least: if you were to go remote today, would you be 100% happy physically working where currently work? If the answer is "no," you may need to re-evaluate.

## Try to get some exercise

From March of 2020 until January of 2022, I gained almost thirty pounds. Part of this weight gain was due to pandemic-related stressors. The biggest source of weight gain, however, was mindless snacking and decreased overall mobility due to working remotely.

In 2022 I've fought back: scheduling walks into my work day, relegating food consumption to meal times, and working out. In addition to the physical health benefits of these newfound habits, I've (annoyingly) found exercise to improve my mood, anxiety, and overall mental well-being.

I didn't grow up in a household that prioritized good fitness or nutrition, so this "common" knowledge came far too late for me: get daily exercise and eat well ... you'll do your body a world of good, and you'll set yourself up for a longer life.[^2]

[^2]: This advice fits regardless of in-office or remote ... work out! It sucks, but it's good!

## Be comfortable being alone

You'll be physically alone most of the day. **Take stock of yourself**: how does that hit you? Keep in mind, you'll still be working with other people--over Slack, on Google Meet or Zoom, etc.--but there's a physicality that's lost, for sure. Are you okay with that?

## ... but still be social

Being physically alone doesn't mean you have to be a loner. In fact, it's more important than ever to build rapport, both at work and outside of work--via Slack, texts, etc. Your mental health will take a hit otherwise.

This advice is especially salient for those of us that are introverted. Your initial inclination may be to lean into your introversion; it was initially mine. But as time goes on, you may find yourself feeling more anxious, struggling with feelings of self-doubt, etc. We are not meant to live alone, so make sure you take steps to avoid that. Socialization doesn't even have to be pointed ... just _being_ around people is enough for me. Activities that fill my "social" cup:

- Go to the gym
- Go to the pool
- Go grocery shopping
- Weekends with friends

They may not seem like much, but these small social interactions are enough to "bring me back into the social fold" 😛

## Conclusion

I'm no expert at remote work. Again, I've only been doing this for three years (with one by choice). And the above is by no means exhaustive. Entire books could be written on "How to Remote Work Well."[^3] Entire blog posts dedicated to effective, constant communication up and down the chain of command. I like the idea of revisiting this blog topic yearly, to see if I feel the same from year-to-year.

Until then, however, that's all I've got; see you next time 😊

[^3]: I purchased [Effective Remote Work][remote-work] as soon as it was released.

[remote-work]: https://pragprog.com/titles/jsrw/effective-remote-work/


Tips and tricks that worked for me while transitioning from in-office work to remote work ... one year in.

What I've learned working remote


Using ES2015, it's possible to initialize objects using computed property names. This is handy for dynamically setting the state in React, for example:

```js
// App.js
import React, { Component } from 'react';

class App extends Component {
  constructor() {
    super()
    this.state = {
      username: ''
    }

    this.handleChange = this.handleChange.bind(this) // Don't forget this!
  }

  // ...

  handleChange(e) {
    this.setState({
      [e.target.name]: e.target.value
    })
  }

  // ...

  render() {
    return (
      <>
        // ...
        <input type="text"
          name="username"
          placeholder="username"
          onChange={this.handleChange}
          value={this.state.username} />
        // ...
      </>
    )
  }
}
```

Note the `handleChange()` method. This method uses a computed property name, `[e.target.name]`, to set the value. This means you can reuse the method to bind multiple elements to state changes with minimal effort.

To add another element, you'd do the following. First, in the `constructor()`:

```js
this.state = {
  // ...
  email: ''
}
```

And in the `render()` function:

```js
<input type="text"
  name="email"
  placeholder="user@example.com"
  onChange={this.handleChange}
  value={this.state.email} />
```


Add two-way binding for arbitrary values using computed property names.

Easier data binding in React

Run tests in VSCode across different languages with Zero Configuration®

TypeScript

Add inline React components to templates similar to Vue

Daniel Strunk

Lead Software Engineer at Promenade Group

Personal projects

dstrunk's GitHub repository, agnostic-test (link opens in a new window)

dstrunk's GitHub repository, inline-jsx (link opens in a new window)

Recent articles

Inline JSX for React

What I've learned working remote

Easier data binding in React

Daniel Strunk

Lead Software Engineer at Promenade Group

Personal projects

dstrunk's GitHub repository, agnostic-test (link opens in a new window)dstrunk/agnostic-test

dstrunk's GitHub repository, inline-jsx (link opens in a new window)dstrunk/inline-jsx

Recent articles

Inline JSX for React

What I've learned working remote

Easier data binding in React

dstrunk's GitHub repository, agnostic-test (link opens in a new window)

dstrunk's GitHub repository, inline-jsx (link opens in a new window)