DEV Community: Dan Bar-Shalom

I've created a text-to-form builder - feedback appreciated

Dan Bar-Shalom — Mon, 19 May 2025 15:42:14 +0000

For several years form-data.com offered a forms-backend as a service, for people building their own static forms.

Creating a form builder was an idea that I played with for a long time. However, as a developer I didn’t like most of the form builders out there. It always feels like I have to fill-in a (really complicated) form just to create a form.

What I ended up with was a text-to-form builder. On the left you write simple text descriptor, and on the right you get a form. And of course, as with any product these days, you can just ask the AI to write it for you. Publish the form is simple, and you’ve got yourself a hosted form.

And the backend gets all you’d expect from a forms the backend, including spam filter, email notifications, auto-response emails and integrations.

I’d really appreciate if you give it a go and share any feedback - the studio is open without registration, and if you want to publish you need to signup without credit-card, and you get 100 free credits.

Try it out here: studio.form-data.com

Next step is releasing the cli so developers can manage the form descriptor as code in their own repo.

You can see the studio in this youtube

Trimming JavaScript: ditch verbosity, gain readability

Dan Bar-Shalom — Sun, 21 Apr 2024 14:32:12 +0000

Are you familiar with expressions like these:

a !== undefined && a !== null ? a : b
if (a.x === undefined || a.x === null) { a.x = b }
{ foo: foo, bar: bar }
a ? a.b : undefined
function getX(o) { return o.x }

What do they all have in common? They are highly verbose, and all have a nice shorthand alternatives. Let's see how we can improve each one of these:

Nullish coalescing operator `??`

This operator checks the value of the left hand-side operand - if it's null or undefined, it returns the right hand-side operand. Otherwise it returns the left hand-side, without evaluating the right hand-side.
This allows simplifying the following expression:

a !== undefined && a !== null ? a : b

To this:

a ?? b

Unlike || operator that checks for any falsy value, this operator only checks for nullish values - meaning null or undefined. Therefore it is safer to use in cases that a is a boolean which can be false or a number which can be 0, and then a || b will return the value of b

Nullish coalescing assignment `??=`

This operator only evaluates the right operand and assigns to the left if the left operand is null or undefined.
So we can simplify this expression:

if (a.x === undefined || a.x === null) { 
  a.x = b 
}

to this:

a.x ??= b

JSON shorthand syntax

The shorthand syntax was introduced with ES6 and is already pretty common.
Use it to shorten this:

const name = 'john doe'
const age = 32
const talk = text => void console.log(text)
const person = {
  name: name,
  age: age,
  talk: talk
}

to that:

const name = 'john doe'
const age = 32
const talk = text => void console.log(text)
const person = {
  name,
  age,
  talk
}

Optional chaining `?.`

This operator accesses an object's property just like . does. However, unlike ., if the object is null or undefined, the expression will return undefined instead of throwing an error.
This allows replacing this code:

a ? a.b : undefined

with that:

a?.b

This operator is pretty strong, and can be used in various ways:

Chaining: a?.b?.c?.d
Call interface method: someInterface.customMethod?.() Note that in this case, if customMethod exists, but it is not a function, you'd still get an exception someInterface.customMethod is not a function
Access dynamic property with bracket notation: x?.[propname]
Access array items: array?.[50] - even if array is nullish, you'd get undefined instead of an exception

Arrow functions

There's a lot to say about arrow functions, but in the context of this post I want to focus on a specific use - 1 liner methods that calculate something or access some property. They have 2 attributes that help with code shortening:

Arrow functions that do not have a block body wrapped with curly brackets {/*...*/} have an implicit return.
in a single-param arrow function you do not have to put the argument in parentheses Meaning, you can change this:

function getX(o) { 
  return o.x 
}

with this

const getX = o => o.x

This is super useful, for example, for mapping functions.
Note that there are some caveats though:

Arrow functions do not have this
Arrow functions do not have arguments. You can use spread operator instead. E.g (...args) => args[0]
Arrow functions cannot call super or be used as constructors

Building an API-product - what is your biggest challenge?

Dan Bar-Shalom — Mon, 19 Feb 2024 04:50:57 +0000

If you are building an API which is a product - what is the biggest challenge for you productizing it?
For me - the API is the easiest part, but everything around can take 5X-10X time to complete:
website, user management, validating API tokens, developer admin panel, docs, etc...

Cover image by RealToughCandy on Pexels

How to structure your code for readability

Dan Bar-Shalom — Mon, 22 Jan 2024 19:44:45 +0000

When writing code, it is often tempting to wrap the main flow inside multiple if statements in order to validate that certain conditions are met.
For example, let's say I'm writing a simple method that returns the length of a string. It might look like this:

function getLength(str) {
  if (typeof str === 'string') {
    return str.length()
  }
  throw new Error('parameter must be a string')
}

While this guards against unexpected parameter types, the main flow is enclosed within an if statement. A more refined approach looks like this:

function getLength(str) {
  if (typeof str !== 'string') {
    throw new Error('parameter must be a string')
  }

  return str.length()
}

On the surface, the distinction may appear subtle, yet the structure of the code makes the main code flow more readable.

This advantage becomes even more apparent when there are multiple exclusion flows. You can turn this nested structure:

function foo() {
  if (/*condition A*/) {
    if (/*condition B*/) {
      if (/*condition C*/) {
        /*main flow*/
      }
      /*handle !condition C*/
    }
    /*handle !condition B*/
  }
  /*handle !condition A*/
}

into this:

function foo() {
  if (/* !condition A */) {
    /* 
    handle !condition A 
    return
    */
  }
  if (/* !condition B */) {
    /* 
    handle !condition B 
    return
    */
  }
  if (/* !condition C */) {
    /* 
    handle !condition C 
    return
    */
  }

  /*main flow*/  
}

The result is cleaner and more readable code, easier to understand and maintain.