npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@deepscribe-marketing/deepscribe-contact-form-logic

v3.4.0

Published

Deepscribe form logic and custom validation

Downloads

116

Readme

Deepscribe form logic and custom validation

This repo contains the logic and custom validation for three forms on the Deepscribe AI Website. To learn how to contribute, please see the contributing guide.

Links of interest:

In a nutshell

This code enables a custom logic and custom form validation for three forms, currently on:

  • /contact
  • /transcription-landing-page-v2
  • /watch-demo

The forms on /contact and /transcription-landing-page-v2 are virtually the same, and share a symbol component in Webflow. Includes custom email validation (with Abstract API + Hubspot forms) and phone number validation following US format + area codes (independent code, no APIs used).

Before starting to work on this project, please take some time to read through the documentation.

Deployed scripts

The following scripts have been deployed for this project: | Name | Latest | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | src/contact/index | https://cdn.jsdelivr.net/npm/@deepscribe-marketing/[email protected]/dist/contact/index.js |

Scripts placement

The following section outlines the specific pages and elements where the deployed scripts should be applied for optimal functionality. It's separated by pages and elements where data attributes are required.

Contact Page

Check on sandbox

Page setup The following scripts must be placed in the Custom Code section of the page settings, right in the "Before body tag":

<!-- Hubspot form -->
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/embed/v2.js"></script>

<!-- Finsweet code -->
<script defer src="https://cdn.jsdelivr.net/npm/@deepscribe-marketing/[email protected]/dist/contact/index.js"></script>

The div with attribute fs-div-element=hubspot_form needs to be set to height 0 and opacity 0 on Webflow. This is required for the hubspot form verification to work properly.

Data attributes

Inside this page, you should add the following attributes to elements:

| Attribute | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | autocomplete="off" | Add to form element, prevents users from being able to go to previous page and resubmit form without completing reCAPTCHA again |

In addition, add all data attributes to target inputs, forms and buttons

Transcription Page v2

Follow same intructions as Contact Page

Watch Demo The following scripts must be placed in the Custom Code section of the page settings, right in the "Before body tag":

<!-- Hubspot form -->
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/embed/v2.js"></script>

After running pnpm build in the terminal, copy the code from dist/watch-demo/index.js

The div with attribute fs-div-element=hubspot_watch_demo_form needs to be set to height 0 and opacity 0 on Webflow. This is required for the hubspot form verification to work properly.

Data attributes

Inside this page, you should add the following attributes to elements:

| Attribute | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | autocomplete="off" | Add to form element, prevents users from being able to go to previous page and resubmit form without completing reCAPTCHA again |

In addition, add all data attributes to target inputs, forms and buttons

Third party services

The following APIs are used in this project:

| Service | Description | | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Absctract API Email Validation | validates real emails, prevents submission from suspicious email addresses | | Hubspot Forms | used for form submission system + adds layer of validation; so that email domains can be blocked via the UI inside Hubspot |

Updating the logic

All files related to the logic for redirecting the user after a successful submission of the contact form can be found inside the src/logic folder. Inside the file, dataset.ts, you can find all the redirect options.

The function getMatchedResult() inside src/logic/index.ts will loop through the entire dataset until it finds a match and will result a redirect link.

A certain redirect will be triggered when all its options have been matched with the user's answers.

When the Hubspot form has been successfully submitted and a match has been found, the redirect(result) function inside src/contact/index will redirect the user to the desired page.

For select inputs that affect the logic, it is important that the values inside the dataset reflect the internal values inside Hubspot, otherwise it will cause issues upon form submission. Some of those values inside Hubspot are not the same as the visible text inside the dropdown options. Some of those examples are: Charm (EHR), Pediatric Medicine (Specialty), Family Medicine (Family Practice). Make sure to match the value inside Webflow options with Hubspot's internal values.

To update the logic, simply add the new values inside each dataset option and check that they match the value (i.e. not the visible text) inside the corresponding option inside Webflow and internal value of the option inside Hubspot (e.g. Family Medicine select option will have: option.text = Family Medicine, option.value = Family Practice, internal value inside hubspot = Family Practice). The internal value inside hubspot has to match the option.value.

For any further information, please contact the Client JS team @ Finsweet.

Publishing NPM Packages

The set up for NPM packages has been integrated into Github actions. Every time a pull request is merged. The latest release can be found inside Github releases in the repo settings.

Finsweet Developer Template General Info

Reference

Included tools

This template contains some preconfigured development tools:

  • Typescript: A superset of Javascript that adds an additional layer of Typings, bringing more security and efficiency to the written code.
  • Prettier: Code formatting that assures consistency across all Finsweet's projects.
  • ESLint: Code linting that enforces industries' best practices. It uses our own custom configuration to maintain consistency across all Finsweet's projects.
  • Playwright: Fast and reliable end-to-end testing.
  • esbuild: Javascript bundler that compiles, bundles and minifies the original Typescript files.
  • Changesets: A way to manage your versioning and changelogs.
  • Finsweet's TypeScript Utils: Some utilities to help you in your Webflow development.

Requirements

This template requires the use of pnpm. You can install pnpm with:

npm i -g pnpm

To enable automatic deployments to npm, please read the Continuous Deployment section.

Getting started

The quickest way to start developing a new project is by creating a new repository from this template.

Once the new repository has been created, update the package.json file with the correct information, specially the name of the package which has to be unique.

Installing

After creating the new repository, open it in your terminal and install the packages by running:

pnpm install

If this is the first time using Playwright and you want to use it in this project, you'll also have to install the browsers by running:

pnpm playwright install

You can read more about the use of Playwright in the Testing section.

It is also recommended that you install the following extensions in your VSCode editor:

Building

To build the files, you have two defined scripts:

  • pnpm dev: Builds and creates a local server that serves all files (check Serving files on development mode for more info).
  • pnpm build: Builds to the production directory (dist).

Serving files on development mode

When you run pnpm dev, two things happen:

  • esbuild is set to watch mode. Every time that you save your files, the project will be rebuilt.
  • A local server is created under http://localhost:3000 that serves all your project files. You can import them in your Webflow projects like:
<script defer src="http://localhost:3000/{FILE_PATH}.js"></script>

Setting up a path alias

Path aliases are very helpful to avoid code like:

import example from '../../../../utils/example';

Instead, we can create path aliases that map to a specific folder, so the code becomes cleaner like:

import example from '$utils/example';

You can set up path aliases using the paths setting in tsconfig.json. This template has an already predefined path as an example:

{
  "paths": {
    "$utils/*": ["src/utils/*"]
  }
}

To avoid any surprises, take some time to familiarize yourself with the tsconfig enabled flags.

Testing

As previously mentioned, this library has Playwright included as an automated testing tool.

All tests are located under the /tests folder. This template includes a test spec example that will help you catch up with Playwright.

After installing the dependencies, you can try it out by running pnpm test. Make sure you replace it with your own tests! Writing proper tests will help improve the maintainability and scalability of your project in the long term.

By default, Playwright will also run pnpm dev in the background while the tests are running, so your files served under localhost:3000 will run as usual. You can disable this behavior in the playwright.config.ts file.

If you project doesn't require any testing, you should disable the Tests job in the CI workflow by commenting it out in the .github/workflows/ci.yml file. This will prevent the tests from running when you open a Pull Request.

Contributing guide

In general, your development workflow should look like this:

  1. Create a new branch where to develop a new feature or bug fix.
  2. Once you've finished the implementation, create a Changeset (or multiple) explaining the changes that you've made in the codebase.
  3. Open a Pull Request and wait until the CI workflows finish. If something fails, please try to fix it before merging the PR. If you don't want to wait for the CI workflows to run on GitHub to know if something fails, it will be always faster to run them in your machine before opening a PR.
  4. Merge the Pull Request. The Changesets bot will automatically open a new PR with updates to the CHANGELOG.md, you should also merge that one. If you have automatic npm deployments enabled, Changesets will also publish this new version on npm.

If you need to work on several features before publishing a new version on npm, it is a good practise to create a development branch where to merge all the PR's before pushing your code to master.

Pre-defined scripts

This template contains a set of predefined scripts in the package.json file:

  • pnpm dev: Builds and creates a local server that serves all files (check Serving files on development mode for more info).
  • pnpm build: Builds to the production directory (dist).
  • pnpm lint: Scans the codebase with ESLint and Prettier to see if there are any errors.
  • pnpm check: Checks for TypeScript errors in the codebase.
  • pnpm format: Formats all the files in the codebase using Prettier. You probably won't need this script if you have automatic formatting on save active in your editor.
  • pnpm test: Will run all the tests that are located in the /tests folder.
  • pnpm test:headed: Will run all the tests that are located in the /tests folder visually in headed browsers.
  • pnpm release: This command is defined for Changesets. You don't have to interact with it.
  • pnpm run update: Scans the dependencies of the project and provides an interactive UI to select the ones that you want to update.

CI/CD

This template contains a set of helpers with proper CI/CD workflows.

Continuous Integration

When you open a Pull Request, a Continuous Integration workflow will run to:

  • Lint & check your code. It uses the pnpm lint and pnpm check commands under the hood.
  • Run the automated tests. It uses the pnpm test command under the hood.

If any of these jobs fail, you will get a warning in your Pull Request and should try to fix your code accordingly.

Note: If your project doesn't contain any defined tests in the /tests folder, you can skip the Tests workflow job by commenting it out in the .github/workflows/ci.yml file. This will significantly improve the workflow running times.

Continuous Deployment

Changesets allows us to generate automatic changelog updates when merging a Pull Request to the master branch.

To generate a new changelog, run:

pnpm changeset

You'll be prompted with a few questions to complete the changelog.

Once the Pull Request is merged into master, a new Pull Request will automatically be opened by a changesets bot that bumps the package version and updates the CHANGELOG.md file. You'll have to manually merge this new PR to complete the workflow.

If an NPM_TOKEN secret is included in the repository secrets, Changesets will automatically deploy the new package version to npm. Keep reading for more info about this.

How to automatically deploy updates to npm

As mentioned before, Changesets will automatically deploy the new package version to npm if an NPM_TOKEN secret is provided.

This npm token should be:

  • From Finsweet's npm organization if this repository is meant for internal/product development.
  • From a client's npm organization if this repository is meant for client development. In this case, you should ask the client to create an npm account and provide you the credentials (or the npm token, if they know how to get it).

Once you're logged into the npm account, you can get an access token by following this guide.

The access token must be then placed in a repository secret named NPM_TOKEN.