Forem: Sharad Chand

Now deploy no-code projects using provided templates in Graftini

Sharad Chand — Wed, 11 Aug 2021 13:01:10 +0000

It can be tedious to create a new project from scratch and to work on it. As a solution for that, we have introduced creating projects from templates.

The following video highlights how you can get started with templates.

We will be adding more templates for the most popular use-cases that you have. So, stay tuned.

Graftini is an no-code SaaS to design and deploy dynamic web apps without having to write a single line of code.

Announcement - Graftini Early Access Release

Sharad Chand — Thu, 29 Jul 2021 07:03:31 +0000

Today we touched a significant milestone. We have been hard at work to move a step closer to our dream of not having to write code for deploying dynamic web apps.

We are releasing the app to the first batch of early access users 🎉. We are extremely psyched yet nervous about it.

The story we would like to tell via Graftini can be summed up in the following three steps:

Think
Design
Deploy

There should not be any extra step involved in bringing an idea to reality. An idea leads to a design which should immediately be shareable for the world to see. No more should there be a lag between design and code.

This is only the first of many iterations to come to the public. With Graftini, you can now:

Build static web apps that can be designed with an intuitive visual builder.
Images that are optimized by default so that the users get an optimized experience.
Deployments that do not take more than a minute.

To try it out, we are offering all our users 2 free projects for the duration of the Early Access (and possibly beyond). These come with the following perks:

10 GB Monthly Bandwidth
Unlimited Pages
Unlimited Deploys
Free Subdomain

We cannot wait to see what you build with it. Cheers to everyone.

If you already have access to Graftini, you can now login here. If you do not have access, you can request for it here.

Note: Since this is early access, there will be bugs that we will be fixing as it comes along.

How to change numeric input by dragging in React?

Sharad Chand — Tue, 29 Jun 2021 12:05:14 +0000

The above GIF is one of the interactions that I love about Figma . To change the position of an item, I do not have to use a keyboard at all. Just a mouse is enough.

So in this article we are going to create a numeric input field whose value can be changed by dragging on its label from scratch. We needed this for Graftini because we think a visual tool should not require keyboard for most interactions.

If you are eager to see the code and try it out for yourself, then jump to CodeSandbox at https://codesandbox.io/s/drag-number-input-z2rnj.

Let us first create a simple input

We can start by creating an input which reads from and writes the values to a state. If you have already created forms this should be simple enough to understand.

function Input() {
  const [value, setValue] = useState(0);

 const onInputChange = useCallback(
    (ev) => setValue(parseInt(ev.target.value, 10)),
    []
  );

  return (
    <input
        value={value}
        onChange={onInputChange}
        style={{
          padding: 8,
        }}
     />
  );
}

We are creating a state which stores the current value of the input. This state will be updated when the input changes via the keyboard.

Now we need a label that fits right in with the input

We need the label to be an anchor on which the mouse interactions can be added. The input itself cannot be the anchor because then it will ruin how input fields normally are expected to behave. The code that captures that idea can look like:

<div
    style={{
      display: "flex",
      border: "1px solid #CCC",
      alignItems: "center",
      borderRadius: 4,
      fontFamily: "sans-serif",
      width: 300,
    }}
>
   <span
      style={{
        padding: 8,
        color: "gray",
        cursor: "ew-resize",
        userSelect: "none",
      }}
    >
      Count
    </span>
   <input
      value={value}
      onChange={onInputChange}
      style={{
        flex: 1,
        padding: 8,
        border: "none",
        outline: "none",
      }}
   />
</div>

The above code is just visual cosmetics. You can make it to look however you see fit. Now the input should look something like:

Adding mouse interactions on the label

We will extract the label into its own component to make it easier to write & understand the code. Then we will add three mouse interactions in it. One on the label itself and two on the document. Why? We will discuss it along side the code.

function DragLabel({ value, setValue }) {
  // We are creating a snapshot of the values when the drag starts
  // because the [value] will itself change & we need the original
  // [value] to calculate during a drag.
  const [snapshot, setSnapshot] = useState(value);

  // This captures the starting position of the drag and is used to 
  // calculate the diff in positions of the cursor.
  const [startVal, setStartVal] = useState(0);

  // Start the drag to change operation when the mouse button is down.
  const onStart = useCallback(
    (event) => {
      setStartVal(event.clientX);
      setSnapshot(value);
    },
    [value]
  );

  // We use document events to update and end the drag operation
  // because the mouse may not be present over the label during
  // the operation..
  useEffect(() => {
    // Only change the value if the drag was actually started.
    const onUpdate = (event) => {
      if (startVal) {
        setValue(event.clientX - snapshot);
      }
    };

    // Stop the drag operation now.
    const onEnd = () => {
      setStartVal(0);
    };

    document.addEventListener("mousemove", onUpdate);
    document.addEventListener("mouseup", onEnd);
    return () => {
      document.removeEventListener("mousemove", onUpdate);
      document.removeEventListener("mouseup", onEnd);
    };
  }, [startVal, setValue, snapshot]);

  return (
    <span
      onMouseDown={onStart}
      style={{
        padding: 8,
        color: "gray",
        cursor: "ew-resize",
        userSelect: "none",
      }}
    >
      Count
    </span>
  );
}

Now try running it up and voila 🎉🎊 you have your own drag to change numeric input.

It looks awesome doesn't it? Though the cursor during the operation does not look good. This could be something that you can fix. 😋

The full code is at CodeSandbox for you to try it out https://codesandbox.io/s/drag-number-input-z2rnj?file=/src/App.js.

Fork it & make improvements to it. Till then ✌️.

Rendering in an iframe in a React app

Sharad Chand — Fri, 04 Jun 2021 04:20:24 +0000

Sometimes you want to render a tree of components within an iframe. You may want to do this because you may be creating something like CodeSandbox that runs other people's code or developing a Storybook-kinda library to design & test components in isolation or you are building a visual editor for designing web apps likes us.

Whatever the reason may be, you would use an iframe for the following two features that iframe offers:

You want to isolate the styles between the parent document and the iframe document. Since the styles are inherited by the children because of the cascading nature of CSS. CSS stands for Cascading Style Sheets after all.

You want to sandbox JS used in an iframe for security. For example, the content in the iframe loads a script from an untrusted location.

As an initial effort to render a component within an iframe, I went ahead by writing the following straight-forward code:



function RenderingInIFrame() {
  return (
    <iframe>
      <MyComponent />
    </iframe>
  );
}

Codesandbox: https://codesandbox.io/s/render-in-iframe-1-eq4tn?file=/src/App.js

It rendered nothing 😭

Boy, to my surprise this did not work because iframe does not expect children. iframe is a nested full-fledged document so adding content to it would not be this simple.

So, I explored the ways that I could do it. The normal way to do it is to add the src attribute with the URL of the app that will run in it. Essentially you would be creating two separate React apps that run in different contexts. This makes it very difficult to share the state between these apps because JS is sandboxed in iframe. You would have to devise complicated setups to share the state and I am not going to explore that here.

Let us try another way that is simple enough, does not require two apps, and can share logic fairly easily. We will need to find a way to render the children within the body of the iframe.

That is where ReactPortal comes to the rescue. Portals are a way to render something virtually at one location and actually render at another. If you want to know more about Portals, you may read them here.

So, we need to create logic where we virtually render at the iframe's children but it renders within iframe's document body. So, here is my hack:



function IFrame({ children }) {
  const [ref, setRef] = useState();
  const container = ref?.contentWindow?.document?.body;

  return (
    <iframe ref={setRef}>
      {container && createPortal(children, container)}
    </iframe>
  );
}

Let me explain line-by-line. Here we created an IFrame wrapper that will render its children in an actual iframe. How we do it is:

Get the ref of the iframe by using useState rather than useRef because useState causes re-render when the ref is set.
We get the body of the iframe document and traverse with optional chaining because ref might not be readily available.
Then we create a portal that renders the children within the body of the iframe.

Now, let us try running the same example while using the newly created IFrame:



function RenderingInIFrame() {
  return (
    <IFrame>
      <MyComponent />
    </IFrame>
  );
}

Codesandbox: https://codesandbox.io/s/render-in-iframe-2-qgy4i?file=/src/App.js

Yay! it works 😃

You can pass in any children to this IFrame and it will work flawlessly. It works this way because the children are rendered in the context of the main app and DOM is updated via Portals. The event handlers on the components within the IFrame also work without issues granted that they are React's synthetic events. For ex:



<IFrame>
  <button onClick={increment}>Increment</button>
</IFrame>

Even though JS and events is not shared between the iframe and the main document, these event handlers work because React emulates the event mechanism using its own synthetic events. So any event that is caught by React will bubble up the tree. For the first time, I have found the why? behind React's own events and they are awesome.

Final Notes

Though you may now know how to render within an iframe by writing an IFrame wrapper from scratch, there is already a library that does this for you and has more features & use-cases built in called react-frame-component.

Hope this has helped you in some way.

Why we chose UUID over SERIAL in PostgreSQL?

Sharad Chand — Fri, 04 Jun 2021 04:15:29 +0000

At Graftini, while we were building schema for the database from the ground up, we faced an age-old question. Whether to use SERIAL or UUID as a primary key. In most of my previous works, I had used SERIAL and why would I not use it. It is fast, size-efficient, and more than anything it just works. Why over-engineer something if it works, right?

The General Problem (https://xkcd.com/974/)

To answer the question, let me tell you a little bit more about Graftini in the context of this article. It has users and projects that the user can create and manage. We created user-facing endpoints similar to /projects/{id} and /users/{id} which the user can navigate to and copy & bookmark. As such, the {id} also has an additional purpose other than being a primary key to uniquely identify a resource. It also has to be secure enough to be shared.

Why we chose UUID over SERIAL?

Because of the above requirements, SERIAL did not fit the bill. Since it is incrementing, anybody can easily guess the next ID and access a resource they were not meant to.

I do not mean to say that using UUID will automatically secure a resource. That it won't. UUID is never an alternative for well-built authentication and authorization. What UUID helps here is the perception that the resource is secure. It provides security through obscurity.

Another reason why SERIAL failed for this use case is that it leaks the meta-information about the system. For example: how many users are there? how many projects exist? This is something that I personally do not feel comfortable sharing with the general public. This information should be limited to appropriate stakeholders and the open internet is not one of them.

Using a UUID helps here because it inherently has no meaning. It is a random string of characters. You won't be able to project any meaningful information out of it.

Are we saying to always use UUID over SERIAL?

No, this post is not written to conclude that UUID is better. Rather we just wanted to show where UUID is appropriate. It is good for user-facing UI and where we do not want to expose any meta-information to the user. Whereas SERIAL is better where the user is not required to directly interact with it. We are using both of them where appropriate and it's fun that way 😄.

What about the slow performance of UUID compared to SERIAL?

I have never seen with my own naked eyes UUID being a source of performance issues. Most of the apps that I have worked with had issues with relation to I/O latency or network latency or memory leakage and never the database itself. From what I have read in other articles, UUID faces problems once it scales. And honestly, I have never worked on a project that has scaled to millions/zillions of users. So, if UUID becomes a performance bottleneck in our app, that would be an awesome problem to have.

Conclusion

All in all, choose whatever suits your requirements or whichever you are most accustomed to. If your requirements ever change in the future or your app becomes mighty popular, hopefully, you will have enough incentive to find a solution to your specific problem.

What is Graftini?

Sharad Chand — Thu, 20 May 2021 12:40:30 +0000

As developers, if we have to do a task, we try to do it in the most efficient way that we know of. Sometimes that means to do it manually. And, if we need to do it again, we oblige. But if we have to do the same repeatedly, the process soon becomes inefficient. And when that time comes, we find a way to automate it.

In our experience, working with clients and having to develop web apps for their specific problems has allowed us to explore new ways of solving them. Even in seemingly unique problems, we began to find repetition in the kind of solution we provided with regards to how we design, review, iterate and write them into code.

That is when it struck us that we need to automate the process. Imagine if we had a thing that lets us design a website using a visual editor, implement behavior without having to write a single line of code, and deploy it to production with a single tap of a button.

We began to scour the internet to find such a thing. We found tools that are tackling similar problems. But they were not able to express our use-cases fully.

Hence we created Graftini. A nocode designer that deploys your designs to full-fledged web apps.

Graftini is where there is no difference between designing and coding, where reviews are only limited to the actual design, and where devops is obsolete. The only task that a developer is responsible for is the design of a solution.

Request for early access to get an early taste when it's available. We are eagerly excited to see the kind of apps you will build with it.

Vue 3's Local <-> Global States

Sharad Chand — Sun, 19 Jul 2020 12:37:16 +0000

With the advent of Vue 3's composition API, one may write local states and its tightly coupled actions like given below:

// maths.js
import { ref } from 'vue';

export function useMaths() {
  const val = ref(0);

  const increment = () => (val.value += 1);
  const decrement = () => (val.value -= 1);

  return {
    val,
    increment,
    decrement,
  };
}

This should look eerily similar to what React offers (if you have used React hooks).

The above code creates a reactive value called val and provides two actions to either increment or decrement this value.

This hook or a composable function can be imported into a component and used directly like so:

<template>
  {{ val }}
  <button @click="increment">Increment</button>
  <button @click="decrement">Decrement</button>
</template>

<script>
  import { useMaths } from './maths';

  export default {
    setup: () => {
      const { val, increment, decrement } = useMaths();
      return {
        val,
        increment,
        decrement,
      };
    },
  };
</script>

The component binds the value and actions to the Vue template. This useMaths hook can be imported into any number of components and the behaviour can be reused while keeping the states local to the component in which it was used.

Vue 3 not only allows us to compose the components and the UI but their behaviour as well.

But what do you do when you realise that the state should have been global instead?

There are times when you could be thinking that a particular state should be local to a component or a page. But as the app progresses on, this assumption may not hold true anymore.

Or there might be instances where you just wanted to experiment with the component and flesh out the internal workings while keeping the implementation simple by using local states. But once the experimentation phase is over you just want to reuse the code as much as possible and adapt it to use a global state.

In these above scenarios, Vue 3 gives us a new trick that we can do with ref that makes this sort of migration negligibly cheap to implement.

See what we do to make the state global in the code below?

// maths.js
import { ref } from 'vue';

const val = ref(0);

export function useMaths() {
  const increment = () => (val.value += 1);
  const decrement = () => (val.value -= 1);

  return {
    val,
    increment,
    decrement,
  };
}

Just move the ref out of the context of the hook and make it global. Vue will take care of the rest. Each component that uses this hook will all share the same val. Now, isn't that something?

PS: This can be done with reactive as well.

Async Redux Actions using Hooks

Sharad Chand — Fri, 03 Jul 2020 06:53:47 +0000

One of the pain points in using Redux has always been writing the same thing over and over again. You create a store with the default values in it, then go on to write a switch case reducer and write an action when an operation is to be done. It gets even more complex when the action is async. I'll not go over it as you most likely have gone through that drill. Of late, Redux has introduced Redux Toolkit to fix these pain points.

The Problem

Before I go into using hooks based actions with Redux, I'll lay out the code structure which I have encountered in all my apps which has some form of async action. For an async action, there are three states of operation: loading, data, error. When the action has not yet been initiated, all the values are falsy (false or null). Once the action is invoked, loading becomes true and on completion loading returns to being false and either data has some value after a successful operation or error has a value if unsuccessful.

This can be laid out in Redux in the following way:

import { createSlice } from '@reduxjs/toolkit';

const store = createSlice({
  name: 'store',
  initialState: {
    loading: false,
    data: null,
    error: null,
  },
  reducers: {
    setLoading: (state) => {
      state.loading = true;
      state.data = null;
      state.error = null;
    },
    setSuccess: (state, action) => {
      state.loading = false;
      state.data = action.payload;
      state.error = null;
    },
    setFailure: (state, action) => {
      state.loading = false;
      state.data = null;
      state.error = action.payload;
    },
  },
});

This is pretty straight-forward and easy to just scaffold to use for smaller programs. But this becomes a problem if there are a lot of slices of data and each one needs to have their own async states be stored. To make a naive solution, we may use a global loading and error states but this becomes a problem when there are two or more async actions which overlap and muddle with this shared state. Also, there is the problem of having to dispatch actions to move the async action to move from one state to another:

// Before async operation.
dispatch(store.actions.setLoading());

try {
  // The async operation is run and it returns data on success.
  dispatch(store.actions.setSuccess(data));
} catch (error) {
  // If an error occurs.
  dispatch(store.actions.setFailure(error));
}

You might already be using redux-thunk to do this or other similar async solution just for API requests.

But why must we do this ritual over and over again for each async action? Here comes hooks to the rescue.

The Solution

Though hooks are the answer to it, I like to use my secret (or not so secret) sauce of react-use's useAsyncFn. This function wraps the async action and generates async states for us. This state is totally unique to this hook and need not be stored in the Redux store. We can selectively store only the required bits from the async action to the Redux store.

// This is the store which stores just the part that we are actually interested in.
const store = createSlice({
  name: 'data',
  initialState: null,
  reducers: {
    setState: (state, action) => {
      state = action.payload;
    },
  },
});

// This is an hook action which constructs and wraps an async action to produces `state` for us.
function useAsyncRequest() {
  const dispatch = useDispatch();

  // `state` maintains the async `loading` and `error` state of the action.
  // `request` is the wrapper of the action which we can invoke in our app.
  const [state, request] = useAsyncFn(async () => {
    const response = await axios.get('/api/data');
    dispatch(store.actions.setState(response.data));
  }, [dispatch]);

  return {
    state,
    request,
  };
}

The state in the above example has the fields state.loading, state.error. And as for the data part, that is directly dispatched and stored within the Redux store. Internally the useAsyncFn wraps the action with a try catch block and stores the loading and error state in its internal variables.

In one of the components, you may use this action like what I have done below:

function Button() {
  const data = useSelector((state) => state.data);
  const { state, request } = useAsyncRequest();

  return (
    <>
      // Show the data from the backend.
      {JSON.stringify(data)}
      <button onClick={request}>{state.loading ? 'Loading' : 'Click'}</button>
    </>
  );
}

Just subscribe to the state changes of the redux and request state; and dispatch an action with the wrapper function request.

The Benefits

You do not have to write loading, error boilerplate code ever again.
No try catch littered in your API requests. They are just wired directly to the async state's error field.
Redux store is neat and focused. It contains only the real data that is to be shown to the user.
The data always comes from the store and the async state from the hooks which to me is a clear separation of concerns. Async state is bound to the actual request where as data to the app.