What's New in JavaScript SDK 1.1

JavaScript SDK 1.1.0 is dated 15 April. Its changelog lists community files, documentation and a new server address, which undersells it: the diff from JavaScript SDK 1.0 also fixes the biggest surprise in 1.0 and adds three features. This post lists all of it, plus two things to know before you upgrade.

The short version

• Fixed: responses now arrive in camelCase, so voteCount, hasVoted and createdAt hold values instead of undefined.
• New: FeedbackSort, with votes, newest, oldest and most-commented orders, passed as sort to feedback.list().
• New: an optional mailing-list opt-in when someone files a request or votes.
• New: isHiddenOverLimit on each request, for requests the Free plan's limit holds back.
• Changed: the default server address moved to getfeedbackkit.com.
• Watch for: includeMerged has no effect in this release, and 1.1 is not on the npm registry.

Installing 1.1

npm install feedbackkit-js still installs 1.0.1: the registry has 1.0.0 and 1.0.1, and no 1.1 build. The 1.1.0 tag is in the SwiftlyFeedbackKit-Javascript-SDK repository on GitHub, but a github: dependency on it does not work, because the tag holds the TypeScript source with no dist folder and no prepare script to build one. To use 1.1, build it from the tag and install the tarball:

git clone --branch 1.1.0 https://github.com/Swiftly-Developed/SwiftlyFeedbackKit-Javascript-SDK.git
cd SwiftlyFeedbackKit-Javascript-SDK
npm install
npm run build
npm pack
# then, in your app:
npm install ../SwiftlyFeedbackKit-Javascript-SDK/feedbackkit-js-1.1.0.tgz

The package name is still feedbackkit-js, so your imports do not change. If a registry install matters more to you than these changes, stay on 1.0.1 and keep the camelCase helper from the JavaScript SDK 1.0 tutorial.

Responses that match the types

The FeedbackKit server speaks snake_case, and 1.0 passed its JSON through untouched, so every two-word field in the types read as undefined at runtime. 1.1 converts in both directions: response keys become camelCase, and request bodies and query names go out in snake_case.

const [top] = await feedbackKit.feedback.list();

// JavaScript SDK 1.0
top.voteCount;   // undefined
top.vote_count;  // 248, but not in the types

// JavaScript SDK 1.1
top.voteCount;   // 248

If you mapped responses yourself, as the 1.0 tutorial does, nothing breaks: a camelCase key passes through that helper unchanged, so you can remove it whenever it suits you. If you read the snake_case names directly, switch to the camelCase ones.

Sort orders

FeedbackSort is a new enum with four values. Votes, the default, puts the most votes at the top. Newest and Oldest sort by when the request was filed, and Comments puts the most-discussed requests at the top. The sort combines with the existing filters:

import { FeedbackKit, FeedbackCategory, FeedbackSort } from 'feedbackkit-js';

const feedbackKit = new FeedbackKit({ apiKey: 'sf_your_api_key', userId: 'trailmate_user_4821' });

const latestBugs = await feedbackKit.feedback.list({
  category: FeedbackCategory.BugReport,
  sort: FeedbackSort.Newest
});

That replaces the in-memory sort the 1.0 tutorial used for a Newest tab.

A mailing-list opt-in

feedback.create() and votes.vote() take two new optional fields. subscribeToMailingList: true records that the person agreed to join your mailing list, and mailingListEmailTypes says which kinds of email they agreed to, such as ['operational']. Leave the types out and the server uses both operational and marketing.

await feedbackKit.votes.vote(feedbackId, {
  userId: 'trailmate_user_4821',
  email: 'hiker@example.com',
  notifyStatusChange: true,
  subscribeToMailingList: true,
  mailingListEmailTypes: ['operational']
});

The opt-in needs an address, so on create() it goes with userEmail and on vote() with email. Where the address goes depends on the project. When it has an active Email Campaign integration (Mailchimp, Kit, beehiiv or MailerLite), the person is added to the chosen list, tagged with the email types. When HubSpot or Salesforce is connected, the address is synced there too. Those integrations need Pro. Show the opt-in as a separate, unticked box, apart from the status-email toggle.

Requests held back by the Free plan

A Free project shows 10 requests. When an 11th arrives, the server saves it and hides it from everyone except the person who filed it, who still sees it when the client sends their user id. On that person's list the request now carries isHiddenOverLimit: true, so your page can say it is waiting for review instead of letting them wonder why nobody votes on it:

if (item.isHiddenOverLimit) {
  note.textContent = 'Received. It will appear on the board after review.';
}

The field is optional in the types, so check for true rather than for presence. On Pro and Team there is no cap.

A new server address

The default baseUrl moved from feedbackkit.swiftly-workspace.com to https://api.prod.getfeedbackkit.com/api/v1. If you leave baseUrl out, you get the new address. If you set it, change it to the new one or remove it. Your API key does not change.

How FeedbackKit fits in

The mailing-list opt-in and the status emails both depend on the address your page collects, which is why the two sit side by side in the vote call. Status emails tell the person who filed a request, and voters who opted in on Team, when it moves on. Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

Upgrading from 1.0

• Build 1.1.0 from the tag, as above, and install the tarball. The registry still serves 1.0.1.
• Replace any snake_case field reads, such as vote_count, with the camelCase names. A mapping helper can stay or go.
• Check a hard-coded baseUrl, or remove it to use the new default.
• Do not rely on includeMerged: true. 1.1 sends it as include_merged, a name the server does not read, so merged requests stay out of the list whatever you pass.
• If you set sort on 1.0.1 by casting around the types, it was dropped there. On 1.1 it reaches the server.

A note on 1.1.1. 1.1.1, tagged on 24 April, changes the version number and nothing else, to match the Swift SDK's 1.1.1 fix. Everything in this post applies to it, and it installs the same way, from the 1.1.1 tag.

The full reference is in the JavaScript SDK docs. If you are starting today, use the current JavaScript tutorial.

Every plan includes the JavaScript SDK. Start free and put the board on your site.