malerba118

Experience

Snowbox

I built a CodeSandbox clone while working at Target to facilitate code-sharing around internal component libraries.

react-esm-sandbox

Library I was working on to bundle and interpret js files directly in the browser. It didn't actually bundle perse, but it augmented import-maps to support importing data-urls which effectively emulated in-browser bundling. Service workers were another effective approach to this. Service workers could intercept esm imports and send back some local code without ever hitting a remote server.

Theming for Gists

I once made an editor to augment GitHub gists and make them look like carbon embeds. Basically was a proxy api that would fetch the gist, prepend some css to it based on some query params, and then send back the js to the client. Looked something like `<script src="https://supergist.com/malerba118/8bb6f5d15522ea1552c301a7098

malerba118

const keyframes = {
   heading: ({ page, fromPx }) => ({
    [page.y - fromPx(50)]: {
      y: 30,
      opacity: 0
    },
    [page.y]: {
      y: 0,
      opacity: 1
    },

malerba118

Story Pointing Thoughts

The estimated time to complete a story is a function of the person who picks up the story. Therefore, we can't decide a good time estimate for a story until it has been assigned. Below are estimations reflecting how long it would take each person to complete each story.

	Austin	Karime
set_up_postgres	3 days	1 day
set_up_redux	1 day	2 days
set_up_cicd	3 days	1 day

malerba118

Ideas for StackBlitz

Dynamic Embed Communication

Using postMessage, send data back and forth dynamically between embeded iframe and parent window. This way, the sandbox could send logs and error messages to parent for custom handling. The parent could also send data to be received by the sandbox and dynamically update the interpreter contents. Iframes are hard to customize and query parameters only allow customization on initialization, but postMessage could introduce a variety of dynamic customization options.

Inline Embeds

Embeds are traditionally tied to persisted projects. Inlined project data passed on the embed url would allow the embedding site to own the code and a sandbox would only be persisted in StackBlitz at the point that the embed is forked. This is powerful for documentation sites so they don't have to be updating their code snippets in multiple places and instead they can have a single source of truth for their code snippets. It also would allow auto-updating dependencies. So

malerba118

// Example taken from https://composition-api.vuejs.org/#usage-in-components
import { reactive, computed, watchEffect } from 'vue'

function setup() {
  const state = reactive({
    count: 0,
    double: computed(() => state.count * 2)
  })

  function increment() {

malerba118

const App = createComponent(() => {  
  const divEl$ = observable(null);
  
  // Do something any time our "ref" changes
  observe(divEl$, (divEl) => {
    console.log(divEl)
  });
  
  return (props, state) => (
    <div ref={divEl$.set}>

malerba118

const App = createComponent(() => {  
  // We can achieve ref functionality via closures
  let divEl = null;
  
  return (props, state) => (
    <div ref={(el) => divEl = el}>
      {/*...*/}
    </div>
  );
});

malerba118

const App = createComponent(({ setState }) => {
  // This is a constructor layer that only runs once.
  // Create observables to hold our counter state.
  const countOne$ = observable(0);
  const countTwo$ = observable(0);
  const countTwoDoubled$ = derived(countTwo$, (countTwo) => {
    return countTwo * 2;
  });

  observe(

malerba118

const App = () => {
  const [countOne, setCountOne] = useState(0);
  const [countTwo, setCountTwo] = useState(0);

  const countTwoDoubled = useMemo(() => {
    return countTwo * 2;
  }, [countTwo]);

  return (
    <div>

malerba118

const count$ = observable(5)

observe(count$, (count) => {
  console.log(count)
})

count$.set(6)
count$.set(7)

// Output: