Skip to content

Commit cde08f1

Browse files
committed
chore: Update TODOs
We've probably done everything that we'll do for now. If people start showing more interest in this project (or if we get more time), we'll start addressing some of the other high-priority TODOs in this document.
1 parent 83d0f21 commit cde08f1

File tree

1 file changed

+5
-6
lines changed

1 file changed

+5
-6
lines changed

TODO.md

+5-6
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,16 @@
11
# TODO
22

3-
## IMMEDIATE
4-
5-
- [ ] Consider adding some GitHub CI Actions to lint our code and run our tests.
6-
- [ ] Consider adding some badges to our Repository's homepage (e.g., Test Coverage).
7-
83
## Documentation
94

105
- [ ] Figure out a Logo for the `enthusiastic-js` Organization and maybe the Form Observer package?
116
- [ ] In the interest of time, we're probably going to have to do the bare minimum when it comes to the documentation. Make the API clear, give some helpful examples, etc. After we've release the first draft of the project, we can start thinking about how to "perfect" the docs. But for now, don't get too paranoid about the wording.
127
- [ ] Adding demos somewhere in this repo (or in something like a CodeSandbox) would likely be helpful for developers. **Edit**: We now have examples for the `FormValidityObserver`. Would examples for the `FormObserver` or the `FormStorageObserver` also be helpful?
138

9+
## Repository
10+
11+
- [ ] Consider adding `Releases` to GitHub and automating the publishing of NPM Packages. (Maybe for the _next_ version? Maybe?)
12+
- [ ] Consider adding some badges to our Repository's homepage (e.g., Test Coverage).
13+
1414
## `FormValidityObserver`
1515

1616
- [ ] Add docs at some point on why we _don't_ allow structuring form data as nested objects like `React Hook Form`, `Conform`, etc.
@@ -44,7 +44,6 @@
4444
## TypeScript
4545

4646
- [ ] `Critical`: Figure out what to do about the broken, overloaded generic constructor types for the `FormObserver` (and its children) -- specifically surrounding generic event types. This _seems_ to be a bug in TypeScript, though it might be intentional since generic constructors are not allowed in `.ts` files at all... We don't want to rewrite our code again, and it seems a little difficult to create separate `.d.ts` files for the generic constructors (_if_ our plan is to cast all of the default exports of classes to the constructor `interface`s). So... We'll wait and see if the TypeScript team will update anything for now. See https://github.com/microsoft/TypeScript/issues/55919 and https://github.com/microsoft/TypeScript/issues/40451. At least all of the other types in our project are good, though! :D And those are the more important types! Plus, if people are using the Framework Integrations, they'll have all the types that they need anyway (at least for form field validation). So... it _should_ be safe to release our package right now.
47-
- [ ] Support custom event types for the `FormObserver` and its children. We technically support custom event types already. However, the TypeScript types don't think so. 😅 (Currently, we only support the standard event types that are recognized by the browser, as far as TypeScript is concerned. For now, people can technically get away with `any` -- though that is undesirable.)
4847

4948
## Testing
5049

0 commit comments

Comments
 (0)