• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

Unleash / unleash / 15489012196
86%
master: 91%

Build:
Build:
LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran 06 Jun 2025 11:07AM UTC
Jobs 1
Files 1175
Run time 3min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

06 Jun 2025 11:01AM UTC coverage: 89.057% (-0.02%) from 89.072%
15489012196

push

github

web-flow
Fix(1-3804)/store flag creation form state (#10089)

Adds caching via localstorage to the flag creation form, so that if you
(accidentally) close the form before submitting it, you'll retain (most)
of the same data when you reopen it.

Specifically, we'll store:
- name
- description
- type
- tags
- impression data

We can't store the project as it is now, because it gets overridden by
whatever is in the URL. However, this is probably a good thing. It means
that if you navigate to a different project and open the feature
creation form there, it'll retain everything from the last one, but
it'll use the current project.

The stored data is cleared when you successfully create a feature, so
that you don't get dangling data.

The data is also stored in a shared cache for all projects, so that you
don't have different caches per project.

The behavior of seeding the form is hidden behind a flag (that doesn't
exist yet). We'll still read and write to the cache if the flag is off,
but we won't use it to populate the feature form, so it has no
discernible impact on the user.

## Bug detected 🐛  ... and squashed

Working on this, I came to realize that there was a bug in how the
config button and use feature form hooks interacted. We (in this case
probably me) have assumed that it's fine to use a set for any option
checking in the config buttons. Also, we're using a set to store tags in
the feature form. But objects aren't compared by value in JS, so the set
will happily accept multiple instances of the same tag. Likewise, these
tags won't show up as selected in the dropdown because when the dropdown
checks if the set `has` the value, it's using reference equality.

To get around this, I have normalized the values of the Tags set to
strings (`<type>:<value>`), which are easily comparable.

We can iterate on this later if we need to.

## `useLocalStorageState`

In doing this, I have also made a change to the useLocalStorageState
hook:
the exposed "setState" func... (continued)

6873 of 6922 branches covered (99.29%)

4 of 4 new or added lines in 1 file covered. (100.0%)

12 existing lines in 2 files now uncovered.

64639 of 72582 relevant lines covered (89.06%)

425.24 hits per line

Uncovered Existing Lines

Lines Coverage ∆ File
6
72.66
-4.69% src/lib/features/playground/feature-evaluator/constraint.ts
6
51.15
-1.15% src/lib/services/email-service.ts
Jobs
ID Job ID Ran Files Coverage
1 15489012196.1 06 Jun 2025 11:07AM UTC 1175
89.06
GitHub Action Run
Source Files on build 15489012196
  • Tree
  • List 1175
  • Changed 3
  • Source Changed 1
  • Coverage Changed 3
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #15489012196
  • c739ea71 on github
  • Prev Build on main (#15487985155)
  • Next Build on main (#15530910154)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc