Form support for Email Field #286

ElijahAhianyo · 2025-04-15T09:44:20Z

Add support for form email fields. This wraps over the EmailAddress type in the email_address crate.

Also refactors and deprecates cot::auth::Password which is replaced by cot::form::types::Passsword.

Example usage:

use cot::db::{model, Auto, Model};
use cot::form::types::{Email, Password};
use cot::auth::PasswordHash

[derive(Debug, Form)]
struct SignupForm {
    fullname: String,
    email: Email,
    username: String,
    password1: Password,
    password2: Password,
}

#[derive(Debug, Clone)]
#[model]
struct User {
    #[model(primary_key)]
    id: Auto<i32>,
    name: String,
    username: String,
    email: Email,
    password: PasswordHash,
}

codecov · 2025-04-15T10:11:52Z

Codecov Report

Attention: Patch coverage is 86.15917% with 40 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cot/src/common_types.rs	79.66%	24 Missing ⚠️
cot/src/form/fields.rs	90.18%	8 Missing and 8 partials ⚠️

Flag	Coverage Δ
rust	`83.10% <86.15%> (+0.12%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
cot/src/admin.rs	`0.00% <ø> (ø)`
cot/src/auth.rs	`91.73% <100.00%> (+0.56%)`	⬆️
cot/src/auth/db.rs	`78.12% <ø> (ø)`
cot/src/form.rs	`77.35% <100.00%> (+10.35%)`	⬆️
cot/src/form/fields.rs	`78.57% <90.18%> (+4.94%)`	⬆️
cot/src/common_types.rs	`79.66% <79.66%> (ø)`

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ElijahAhianyo · 2025-04-16T01:24:22Z

cot/src/form/types.rs

@@ -0,0 +1,351 @@
+//! Form Field Types for Cot


still deliberating on whether it's useful to have this file than put everything in fields.rs(open to ideas on this)

I think it will be useful, but perhaps we could move it directly to crate::types, given it's useful not only in forms, but also in auth. I'm not 100% sold on the name types, though; it's very generic. I'm thinking about something in the lines of value_types or data.

@seqre do you have any additional views on this?

I think it will be useful, but perhaps we could move it directly to crate::types, given it's useful not only in forms, but also in auth.

I agree, Password and Email (and other similar types) are so common that it makes sense to extract them to their own place, so they can be reused in different situations.

I'm not 100% sold on the name types, though; it's very generic. I'm thinking about something in the lines of value_types or data.

I'm bad at naming as well, but some other ideas that come to my mind: common_types, user_types, or user_data. I'd be against plain data as it's too generic like types.

common_types sounds good to me, but I also like value_types 🤔

ended up going with common_types. Anyone with an objection, speak now or forever hold your peace 😅

ElijahAhianyo · 2025-04-22T18:07:30Z

@m4tx I'm definitely doing something wrong, which makes the CI fail, that is not obvious to me. Do you have any pointers on what that may be?

cot/src/form/types.rs

m4tx · 2025-04-22T18:17:08Z

@m4tx I'm definitely doing something wrong, which makes the CI fail, that is not obvious to me. Do you have any pointers on what that may be?

Yes, the #[cfg(feature)] attributes seem to be wrong - see my review comment. The CI is failing on cargo build --features mysql essentially, so you should be able to test this locally, too.

cot/src/auth.rs

m4tx

Overall looks good, please have a look at the comments and this will be ready to merge soon!

m4tx · 2025-04-22T21:02:29Z

cot/src/form/types.rs

@@ -0,0 +1,351 @@
+//! Form Field Types for Cot


I think it will be useful, but perhaps we could move it directly to crate::types, given it's useful not only in forms, but also in auth. I'm not 100% sold on the name types, though; it's very generic. I'm thinking about something in the lines of value_types or data.

@seqre do you have any additional views on this?

m4tx · 2025-04-22T21:08:46Z

cot/src/form/types.rs

+    /// assert_eq!(domain, "example.com");
+    /// ```
+    #[must_use]
+    pub fn as_inner(&self) -> &EmailAddress {


Do you think it makes sense to remove this as_inner method and instead expose the methods that could be potentially useful for users (like domain(), local_part(), etc.) instead? We generally try not to expose crates we depend on unnecessarily, as it makes it harder to swap these crates for different ones in the future, or even upgrade their versions (because every major version bump of an exposed crate results in a breaking change for us, too).

EmailAddress does not have many methods, so I'd agree on getting rid of as_inner and just exposing those methods via our interface. An alternative option is to replace it with the implementation of Into<EmailAddress> for it, which might be arguably a bit nicer to get rid of/deprecate in the future.

Thanks for the suggestion—I think that makes sense. I originally added as_inner() as an escape hatch for anyone needing extra functionality, but exposing the specific methods we actually use on Email sounds great. We’ll just need to update those forwards if we ever swap out the underlying crate, which shouldn’t be too burdensome.

@seqre As for the Into<EmailAddress> escape hatch, on second thought, my main concern is version conflicts: if consumers import EmailAddress directly from the email_address crate, bumping our dependency could suddenly break their builds. Do you think this will be a genuine concern, or do you propose we go with the first approach?

@seqre I ended up going with the first approach, I'm still unsure what the idiomatic approach is, or if the second approach is a genuine concern. If it isn't, let me know and I'll be happy to go in that direction.

cot/src/form/fields.rs

seqre · 2025-04-22T21:50:58Z

cot/src/form/types.rs

+    /// assert_eq!(domain, "example.com");
+    /// ```
+    #[must_use]
+    pub fn as_inner(&self) -> &EmailAddress {


EmailAddress does not have many methods, so I'd agree on getting rid of as_inner and just exposing those methods via our interface. An alternative option is to replace it with the implementation of Into<EmailAddress> for it, which might be arguably a bit nicer to get rid of/deprecate in the future.

seqre · 2025-04-22T22:00:59Z

cot/src/form/types.rs

@@ -0,0 +1,351 @@
+//! Form Field Types for Cot


I think it will be useful, but perhaps we could move it directly to crate::types, given it's useful not only in forms, but also in auth.

I agree, Password and Email (and other similar types) are so common that it makes sense to extract them to their own place, so they can be reused in different situations.

I'm not 100% sold on the name types, though; it's very generic. I'm thinking about something in the lines of value_types or data.

I'm bad at naming as well, but some other ideas that come to my mind: common_types, user_types, or user_data. I'd be against plain data as it's too generic like types.

m4tx

Looks good to me, thanks for this high-quality contribution!

I'll leave the last word to @seqre in case he has any outstanding comments, but from my side this should be ready to be merged.

m4tx · 2025-04-25T15:29:46Z

cot/src/form/fields.rs

+            if min > max {
+                return Err(FormFieldValidationError::from_string(format!(
+                    "min_length ({min}) exceeds max_length ({max})"
+                )));
+            }


Ah, it would probably make sense to have some sort of mechanism to enforce this when constructing the field, rather than when cleaning the value. This is obviously out of scope of this PR, but I'll create an issue to keep this in the roadmap. EDIT: done #294

seqre

Great work, just one last thing and I'll gladly approve!

cot/src/common_types.rs

seqre

Once again, great work and thank you for your contribution!

github-actions bot added the C-lib Crate: cot (main library crate) label Apr 15, 2025

ElijahAhianyo commented Apr 16, 2025

View reviewed changes

ElijahAhianyo force-pushed the elijah/email-field branch from 976f503 to d7ee403 Compare April 16, 2025 01:54

ElijahAhianyo marked this pull request as ready for review April 16, 2025 02:01

ElijahAhianyo changed the title ~~[WIP]Form support for Email Field~~ Form support for Email Field Apr 16, 2025

m4tx reviewed Apr 22, 2025

View reviewed changes

cot/src/form/types.rs Outdated Show resolved Hide resolved

m4tx reviewed Apr 22, 2025

View reviewed changes

cot/src/auth.rs Outdated Show resolved Hide resolved

m4tx requested changes Apr 22, 2025

View reviewed changes

seqre requested changes Apr 22, 2025

View reviewed changes

ElijahAhianyo force-pushed the elijah/email-field branch from 6625487 to 5bb236b Compare April 23, 2025 20:17

ElijahAhianyo requested review from m4tx and seqre April 24, 2025 10:58

m4tx approved these changes Apr 25, 2025

View reviewed changes

m4tx mentioned this pull request Apr 25, 2025

Form fields' custom options should be validated when constructing the field #294

Open

seqre requested changes Apr 26, 2025

View reviewed changes

cot/src/common_types.rs Outdated Show resolved Hide resolved

ElijahAhianyo requested a review from seqre April 27, 2025 11:19

seqre approved these changes Apr 27, 2025

View reviewed changes

ElijahAhianyo and others added 10 commits April 27, 2025 13:20

Form support for Email Field

fae7888

Add tests, docs and refactor

0f01553

add more tests

be709f5

chore(pre-commit.ci): auto fixes from pre-commit hooks

373e4b5

move password out of auth

916c05d

show deprecated msg

f6284f2

rebase

4b80a30

fix fmt precommit

05a7a17

gate behind db feature

c4ce1b9

fix feature build

efff8b8

ElijahAhianyo and others added 8 commits April 27, 2025 13:20

rename to common_types and move to root namespace

dde5b54

chore(pre-commit.ci): auto fixes from pre-commit hooks

bea2d1c

remove punctuation

1fc3b9c

forward methods instead of escape hatch

8d1262e

fix doc tests

43f438e

i thought i fixed this?

f66244b

dang clippy

2a4c0e9

to_db_value should always use the normalized email.

e24d530

seqre force-pushed the elijah/email-field branch from aea98ff to e24d530 Compare April 27, 2025 11:20

seqre changed the title ~~Form support for Email Field~~ feat: add form support for Email Field Apr 27, 2025

seqre enabled auto-merge (squash) April 27, 2025 11:21

seqre disabled auto-merge April 27, 2025 11:22

seqre changed the title ~~feat: add form support for Email Field~~ Form support for Email Field Apr 27, 2025

seqre enabled auto-merge (squash) April 27, 2025 11:28

seqre merged commit bfbfdad into cot-rs:master Apr 27, 2025
19 checks passed

cotbot bot mentioned this pull request Apr 27, 2025

chore: release v0.3.0 #274

Merged

Uh oh!

Form support for Email Field #286

Form support for Email Field #286

Uh oh!

Conversation

ElijahAhianyo commented Apr 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Apr 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ElijahAhianyo Apr 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ElijahAhianyo commented Apr 22, 2025

Uh oh!

Uh oh!

m4tx commented Apr 22, 2025

Uh oh!

Uh oh!

m4tx left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ElijahAhianyo Apr 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

m4tx left a comment

Choose a reason for hiding this comment

Uh oh!

m4tx Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seqre left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

seqre left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ElijahAhianyo commented Apr 15, 2025 •

edited

Loading

codecov bot commented Apr 15, 2025 •

edited

Loading

ElijahAhianyo Apr 16, 2025 •

edited

Loading

ElijahAhianyo Apr 23, 2025 •

edited

Loading

m4tx Apr 25, 2025 •

edited

Loading