DEV Community: Typelets Team

Building a Native Rich Text Editor for React Native

Typelets Team — Sat, 22 Nov 2025 04:02:37 +0000

We needed a rich text editor for our cross-platform note-taking app. The web version used TipTap, and we wanted the mobile version to feel native while keeping content perfectly synced. After trying every React Native editor library out there, we built our own. Here's why and how.

The Problem

When we started building Typelets' mobile app, we assumed we'd just plug in an existing rich text editor library. We were wrong.

What we tried:

react-native-pell-rich-editor - Laggy, inconsistent formatting
react-native-cn-quill - Heavy bundle, sync issues with TipTap HTML
@10play/tentap-editor - Promising, but we needed more control over the HTML output
Various markdown editors - Not the UX we wanted

The core issues:

Performance - Most editors felt sluggish, especially with longer documents
HTML Compatibility - Output didn't match TipTap's structure, causing sync nightmares
Customization - We needed specific behaviors (task lists, code blocks) that were hard to customize

We needed an editor that:

Felt native on mobile
Produced HTML identical to TipTap's output
Gave us full control over keyboard behavior
Handled task lists, code blocks, and nested lists correctly

The Architecture Decision

Instead of fighting with libraries, we built a WebView bridge pattern:

┌─────────────────────────────────────────────────┐
│              React Native Layer                 │
│  ┌─────────────┐  ┌─────────────────────────┐   │
│  │   Toolbar   │  │    Editor Component     │   │
│  │  (Native)   │  │     (WebView Host)      │   │
│  └─────────────┘  └─────────────────────────┘   │
│         │                    │                  │
│         │    postMessage()   │                  │
│         ▼                    ▼                  │
├─────────────────────────────────────────────────┤
│                WebView Layer                    │
│  ┌─────────────────────────────────────────┐    │
│  │     contenteditable div + JavaScript    │    │
│  │     (Custom selection, formatting,      │    │
│  │      keyboard handlers)                 │    │
│  └─────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘

Why this works:

Native toolbar = snappy UI
WebView editor = full control over HTML
Message passing = clean separation of concerns
Same HTML format = perfect TipTap compatibility

The Implementation

1. The Bridge Protocol

Communication happens via JSON messages between React Native and the WebView:

// WebView → React Native
interface EditorMessage {
  type: 'content' | 'formats' | 'height';
  html?: string;
  formats?: FormatState;
  height?: number;
}

// React Native → WebView (via injectJavaScript)
window.execCommand('bold');
window.execCommand('heading', 2);
window.setContent('<p>Initial content</p>');

2. The Core Editor Component

Click to see the full Editor component

// Editor.tsx (simplified)
export const Editor = ({
  initialContent,
  onChange,
  colors
}: EditorProps) => {
  const webViewRef = useRef<WebView>(null);
  const [formats, setFormats] = useState<FormatState>({});

  const handleMessage = (event: WebViewMessageEvent) => {
    const data = JSON.parse(event.nativeEvent.data);

    switch (data.type) {
      case 'content':
        onChange?.(data.html);
        break;
      case 'formats':
        setFormats(data.formats);
        break;
      case 'height':
        // Adjust WebView height dynamically
        break;
    }
  };

  const execCommand = (command: string, value?: string) => {
    webViewRef.current?.injectJavaScript(
      `window.execCommand('${command}'${value ? `, '${value}'` : ''});`
    );
  };

  return (
    <>
      <Toolbar formats={formats} onCommand={execCommand} />
      <WebView
        ref={webViewRef}
        source={{ html: generateEditorHTML(initialContent, colors) }}
        onMessage={handleMessage}
        keyboardDisplayRequiresUserAction={false}
      />
    </>
  );
};

3. The WebView HTML (The Secret Sauce)

This is where the magic happens. We generate HTML that includes:

A contenteditable div
Custom keyboard handlers
Selection tracking
Format detection

Click to see the WebView JavaScript

// Inside the WebView
const editor = document.getElementById('editor');

// Track selection changes to update toolbar
document.addEventListener('selectionchange', () => {
  const formats = {
    bold: document.queryCommandState('bold'),
    italic: document.queryCommandState('italic'),
    underline: document.queryCommandState('underline'),
    // Custom detection for block elements
    heading: detectHeadingLevel(),
    bulletList: isInsideElement('UL:not([data-type])'),
    orderedList: isInsideElement('OL'),
    taskList: isInsideElement('[data-type="taskList"]'),
    codeBlock: isInsideElement('PRE'),
    blockquote: isInsideElement('BLOCKQUOTE'),
  };

  window.ReactNativeWebView.postMessage(
    JSON.stringify({ type: 'formats', formats })
  );
});

// Content changes
editor.addEventListener('input', () => {
  window.ReactNativeWebView.postMessage(
    JSON.stringify({ type: 'content', html: editor.innerHTML })
  );
});

4. Custom Keyboard Handling (The Hard Part)

The biggest challenge was making Enter and Backspace behave correctly in different contexts. TipTap has specific behaviors for lists, code blocks, and task items. We had to replicate them:

Click to see keyboard handling code

editor.addEventListener('keydown', (e) => {
  if (e.key === 'Enter') {
    e.preventDefault();

    const context = getSelectionContext();

    if (context.inCodeBlock) {
      // Insert literal newline, don't create new paragraph
      insertTextAtCursor('\n');
    }
    else if (context.inTaskList) {
      // Create new task item with same structure
      createNewTaskItem();
    }
    else if (context.inList) {
      // Create new list item, or exit list if empty
      if (context.isEmpty) {
        exitList();
      } else {
        createNewListItem();
      }
    }
    else {
      // Normal paragraph
      document.execCommand('insertParagraph');
    }
  }
});

5. TipTap-Compatible HTML Structure

This is crucial. TipTap expects specific HTML structures. If your mobile editor generates different HTML, you'll have sync issues.

Task Lists (TipTap format):

<ul data-type="taskList">
  <li data-type="taskItem" data-checked="false">
    <label>
      <input type="checkbox">
      <span></span>
    </label>
    <div><p>Task text here</p></div>
  </li>
</ul>

List Items (TipTap wraps content in <p>):

<ul>
  <li><p>Item one</p></li>
  <li><p>Item two</p></li>
</ul>

Code Blocks:

<pre><code class="language-javascript">const x = 1;</code></pre>

We had to ensure every operation in our mobile editor produces this exact structure.

The Web Side (TipTap)

On web, we use TipTap with custom extensions:

// editor-config.ts
export const createEditorExtensions = () => [
  StarterKit.configure({
    heading: { levels: [1, 2, 3] },
    codeBlock: false, // We use custom code block
  }),
  TaskList,
  TaskItem.configure({ nested: true }),
  CodeBlockLowlight.configure({ lowlight }),
  Underline,
  Link,
  Highlight,
  // Custom extensions
  ExecutableCodeBlock,
  ResizableImage,
  SlashCommands,
];

The key insight: both editors output the same HTML format. No conversion needed.

Syncing Content

Because both platforms produce identical HTML, syncing is trivial:

// Shared Note type
interface Note {
  id: string;
  title: string;
  content: string; // HTML - same format everywhere
  updatedAt: Date;
}

Challenges We Solved

1. Dynamic Height

WebViews have fixed height by default. We needed the editor to grow with content:

// In WebView
const reportHeight = () => {
  const height = document.documentElement.scrollHeight;
  window.ReactNativeWebView.postMessage(
    JSON.stringify({ type: 'height', height })
  );
};

new MutationObserver(reportHeight).observe(editor, {
  childList: true,
  subtree: true,
  characterData: true,
});

2. Theme Support

We pass theme colors from React Native into the WebView:

const generateEditorHTML = (content: string, colors: EditorColors) => `
  <style>
    body {
      background: ${colors.background};
      color: ${colors.foreground};
    }
    blockquote {
      border-left: 3px solid ${colors.blockquoteBorder};
    }
  </style>
  <div id="editor" contenteditable="true">${content}</div>
`;

3. Keyboard Dismissal

On iOS, the keyboard doesn't dismiss easily with WebView. We added a "Done" button:

webViewRef.current?.injectJavaScript('document.activeElement.blur();');
Keyboard.dismiss();

4. Selection Preservation

When switching between apps or screens, selection can be lost:

let savedSelection = null;

window.saveSelection = () => {
  const sel = window.getSelection();
  if (sel.rangeCount > 0) {
    savedSelection = sel.getRangeAt(0).cloneRange();
  }
};

window.restoreSelection = () => {
  if (savedSelection) {
    const sel = window.getSelection();
    sel.removeAllRanges();
    sel.addRange(savedSelection);
  }
};

Performance Results

After switching to this architecture:

Metric	Result
Input latency	~16ms (feels native)
Content sync	Instant (same format)
Bundle size	Smaller than Quill-based solutions
Large documents	Handles 10k+ words smoothly

Lessons Learned

Don't fight the platform - WebView for rich text is fine. It's what every rich text editor uses anyway.
HTML is a great interchange format - Instead of trying to use the same library everywhere, use the same data format.
Keyboard handling is 80% of the work - Getting Enter/Backspace right in different contexts took longer than everything else combined.
Test on real devices - Simulator behavior differs from real devices, especially for keyboard and selection.
Copy TipTap's HTML exactly - Read TipTap's source to understand exactly what HTML it produces. Match it.

Should You Do This?

Yes, if:

You need perfect compatibility with a web editor
You want full control over behavior
Performance matters to your users
You have complex formatting needs (task lists, code blocks, etc.)

No, if:

Basic formatting is enough
You can live with some HTML differences
You don't have time to handle edge cases

Resources

TipTap Documentation

react-native-webview on GitHub

Building a rich text editor is hard. Building one that works across platforms is harder. But with the right architecture, it's absolutely doable.

The key insight is that you don't need the same library everywhere - you need the same data format.

Happy coding!

We built this for Typelets, a cross-platform note-taking app. If you're working on something similar, feel free to reach out!

Check out Typelets

How We Built Zero-Knowledge Encryption in the Browser

Typelets Team — Sat, 26 Jul 2025 20:42:24 +0000

How We Built Zero-Knowledge Encryption in the Browser (So We Can't Read Your Notes)

Most note-taking apps claim to be "encrypted" but still have a dirty secret: they can read all your data. When we built Typelets, we decided to do things differently - using true zero-knowledge encryption where even we can't decrypt your notes.

Here's exactly how we did it using just the Web Crypto API.

The Problem That Made Us Build Typelets

When apps like Notion say they're encrypted, they usually mean:

✅ HTTPS encryption in transit
✅ Database encryption at rest
❌ They still hold the keys to decrypt everything

We wanted to build a notes app where privacy wasn't just a marketing claim - it was mathematically guaranteed. That's why we created Typelets with zero-knowledge architecture.

How Typelets' Zero-Knowledge Encryption Works

In Typelets, here's what happens when you create a note:

🔐 Data encrypted on your device before transmission
🔑 Encryption keys never leave your browser
🚫 We literally cannot decrypt your data
🛡️ Even if our servers get hacked, attackers get useless encrypted blobs

Implementation: The Technical Details

Here's the actual code powering Typelets' encryption. Every user must set a master password that never leaves their device:

1. Master Password Setup

async setupMasterPassword(masterPassword: string, userId: string): Promise<void> {
  // Create user-specific salt
  const userSalt = `typelets-salt-${userId}-v1`

  const encoder = new TextEncoder()
  const passwordBytes = encoder.encode(masterPassword)
  const saltBytes = encoder.encode(userSalt)

  // Import password as key material
  const keyMaterial = await crypto.subtle.importKey(
    'raw',
    passwordBytes,
    { name: 'PBKDF2' },
    false,
    ['deriveKey']
  )

  // Derive encryption key from master password
  const encryptionKey = await crypto.subtle.deriveKey(
    {
      name: 'PBKDF2',
      salt: saltBytes,
      iterations: 250000, // High iteration count for security
      hash: 'SHA-256'
    },
    keyMaterial,
    { name: 'AES-GCM', length: 256 },
    false,
    ['encrypt', 'decrypt']
  )

  // Store derived key locally in browser (never sent to server)
  await this.storeKeyInSecureStorage(userId, encryptionKey)
}

Critical security feature: The master password never leaves your browser. Even if someone knows your userId, they cannot decrypt your notes without your password.

2. Key Derivation on Unlock

async unlockWithMasterPassword(
  masterPassword: string,
  userId: string
): Promise<boolean> {
  // Create user-specific salt (same as setup)
  const userSalt = `typelets-salt-${userId}-v1`

  const encoder = new TextEncoder()
  const passwordBytes = encoder.encode(masterPassword)
  const saltBytes = encoder.encode(userSalt)

  // Re-derive the key
  const keyMaterial = await crypto.subtle.importKey(
    'raw',
    passwordBytes,
    { name: 'PBKDF2' },
    false,
    ['deriveKey']
  )

  const derivedKey = await crypto.subtle.deriveKey(
    {
      name: 'PBKDF2',
      salt: saltBytes,
      iterations: 250000,
      hash: 'SHA-256'
    },
    keyMaterial,
    { name: 'AES-GCM', length: 256 },
    false,
    ['encrypt', 'decrypt']
  )

  // Verify by attempting to decrypt a test note
  // If successful, cache the key for the session
  return await this.verifyKey(derivedKey, userId)
}

3. How Typelets Encrypts Your Notes

// This runs in your browser when you save a note in Typelets
async encryptNote(
  userId: string,
  title: string,
  content: string
): Promise<EncryptedNote> {
  // Get encryption key (derived from master password)
  const key = await this.getEncryptionKey(userId)

  // Generate random IV for this note (ensures same content encrypts differently)
  const iv = crypto.getRandomValues(new Uint8Array(12))
  const encoder = new TextEncoder()

  // Encrypt title and content separately
  const titleBytes = encoder.encode(title)
  const contentBytes = encoder.encode(content)

  const encryptedTitleBuffer = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    key,
    titleBytes
  )

  const encryptedContentBuffer = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    key,
    contentBytes
  )

  return {
    encryptedTitle: this.arrayBufferToBase64(encryptedTitleBuffer),
    encryptedContent: this.arrayBufferToBase64(encryptedContentBuffer),
    iv: this.arrayBufferToBase64(iv)
  }
}

4. What Typelets' Database Actually Stores

Our PostgreSQL database only ever sees encrypted data:

// What Typelets stores (completely encrypted)
notes: {
  id: "note_123",
  encrypted_title: "kJ9fX2zR8vQ...", // Encrypted blob
  encrypted_content: "mP4sL7nE1wY...", // Encrypted blob
  iv: "aB3dF6gH9jK...", // Initialization vector (safe to be public)
  user_id: "user_456" // Only metadata we can see
}

// What Typelets NEVER sees
{
  title: "My secret thoughts", // ❌ Never stored in plaintext
  content: "Today I...",        // ❌ Never stored in plaintext
  master_password: "...",       // ❌ Never leaves your device
  encryption_key: "..."         // ❌ Never leaves your device
}

Addressing Security Concerns

Q: "If you use userId as input to key derivation, can't anyone generate the same key?"

Great question! This was actually a concern with our earlier implementation. Here's how we've addressed it:

Current implementation:

Key derivation: PBKDF2(masterPassword, userSalt) with 250,000 iterations
User-specific salt: typelets-salt-${userId}-v1 (unique per user, but public)
Secret component: The master password that ONLY the user knows

Why this is secure:
Even if an attacker knows:

✅ The userId
✅ The salt formula
✅ The iteration count
✅ The algorithm (PBKDF2-SHA256)

They cannot decrypt without the user's master password. The salt prevents rainbow table attacks, but the master password is what provides the actual security.

Result: True zero-knowledge architecture where we literally cannot access user data, even if compelled by law.

Security Considerations

The Good

Unbreakable privacy: AES-256-GCM with 250,000 PBKDF2 iterations
Perfect forward secrecy: Each note has unique IV
No server-side keys: We can't decrypt even if legally compelled
Browser security: Leverages battle-tested Web Crypto API
Zero-knowledge verified: Mathematical guarantee of privacy
No password recovery: By design - we never see your password

The Tradeoffs

Lost password = lost data: If you forget your master password, your notes are permanently inaccessible
No server-side search: We can't index encrypted content (client-side search only)
Limited analytics: We can't analyze usage patterns in content
Session re-authentication: Must re-enter password after browser restart
Master password requirement: Users must remember a strong password

Why No Password Recovery?

This is intentional. If we could recover your password, we could decrypt your data - breaking the zero-knowledge guarantee. True privacy means accepting this tradeoff.

Performance Impact

Surprisingly minimal:

Encryption time: ~2ms for typical note (1000 chars)
Key derivation: ~500ms with 250k iterations (only on unlock/setup)
Decryption time: ~1ms per note
Bundle size: 0 bytes (uses native Web Crypto API)
Battery impact: Negligible on modern devices

The 250k PBKDF2 iterations only run when setting up or unlocking (once per session), so day-to-day usage is extremely fast.

Why We Built Typelets This Way

In an era where AI companies train on user data and governments demand backdoors, we wanted to create a notes app that was truly private by design.

The result? Even under legal pressure, we can only hand over encrypted blobs that are mathematically useless without the user's master password.

Real-World Implementation

This isn't theoretical - you can see this encryption in action:

Visit app.typelets.com
Create an account and set your master password
Open your browser's DevTools → Network tab
Create a note and watch the request payload
You'll see only encrypted data being transmitted

Here's what an actual API request looks like:

POST /api/notes
{
  "encryptedTitle": "kJ9fX2zR8vQmP4sL7nE1wY...",
  "encryptedContent": "aB3dF6gH9jKmN8pQ2rT5vX...",
  "iv": "yZ1cE4fG7hI0jL3mN6oP9q..."
}

Our server literally cannot read what you're saving.

Try Typelets' Zero-Knowledge Encryption

You can experience this encryption in action at app.typelets.com. Open your browser's dev tools and watch the encryption happen client-side - it's pretty cool to see your data get scrambled before it leaves your device.

We've also published our security architecture at typelets.com/security if you want to dive deeper into the technical details.

Building Your Own Zero-Knowledge App?

The Web Crypto API makes client-side encryption surprisingly straightforward. The hardest part isn't the crypto - it's designing your entire app architecture around never seeing user data.

Key lessons we learned:

Always require a user secret - Don't rely on userId or derivable values alone
Make salts user-specific - Even though they're public, they prevent rainbow tables
Use high iteration counts - 250k+ PBKDF2 iterations slow down brute force attacks
Never transmit the master password - It should never leave the user's device
Accept the tradeoff - No password recovery means permanent data loss if forgotten
Session key caching - Keep the derived key in memory during the session for performance
Clear documentation - Users need to understand the implications of zero-knowledge

Security checklist for zero-knowledge apps:

[ ] Master password never sent to server
[ ] Encryption happens client-side before transmission
[ ] Server stores only encrypted data
[ ] Decryption only possible on client
[ ] User-specific salts (even if predictable)
[ ] High PBKDF2 iteration count (250k+)
[ ] Clear warning about data loss if password forgotten

Questions for the community:

How do you handle encryption in your apps?
What other zero-knowledge services do you use?
How do you balance security vs. user convenience?

Drop a comment - I'd love to discuss the technical challenges and tradeoffs of privacy-first development!

Want to see the full implementation? Check out our GitHub repo or explore the security architecture docs.