Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix : reduce css file size #94

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

Conversation

anonymousRecords
Copy link
Member

@anonymousRecords anonymousRecords commented Feb 16, 2025

Description of Changes

related #93

  • Before: Direct use of KaTeX with full CSS import
  • After: Use @matejmazur/react-katex and manage only necessary fonts and styles directly

Reduce css file size

Through this optimization work, I reduced the CSS file size by approximately 98.43%.

[AS-IS]

  • KaTeX fonts are directly embedded in CSS as Base64 encoded strings
  • Duplicate KaTeX import issue
dist/index.css        1,480.96 kB │ gzip: 950.98 kB
dist/notionpresso.js    708.54 kB │ gzip: 189.69 kB
dist/index.css         1,480.96 kB │ gzip: 950.98 kB
dist/notionpresso.cjs    481.49 kB │ gzip: 151.89 kB

[TO-BE]

  • Use @matejmazur/react-katex
  • Manage only necessary fonts and styles directly
dist/index.css         23.20 kB │ gzip:   5.41 kB
dist/notionpresso.js  661.58 kB │ gzip: 177.71 kB
dist/index.css          23.20 kB │ gzip:   5.41 kB
dist/notionpresso.cjs  448.92 kB │ gzip: 141.74 kB

Review point

  • Can I reuse the Equation component in the RichText component?
  • It seems KaTeX is no longer being used - is it safe to remove it?

Screenshot

image

Comment on lines +17 to +21
<Equation
key={index.toString()}
inline
{...(text as unknown as EquationArgs)}
/>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can I reuse the Equation component in the RichText component?

@anonymousRecords anonymousRecords changed the title Fix/reduce css file size fix : reduce css file size Feb 16, 2025
@Moon-DaeSeung
Copy link
Contributor

Moon-DaeSeung commented Feb 16, 2025

you should show storybook screenshot about equation component

@anonymousRecords
Copy link
Member Author

@Moon-DaeSeung

you should show storybook screenshot about equation component

I attached a screenshot

import TeX from "@matejmazur/react-katex";

import { EquationArgs } from "../types";

const Equation = ({ equation: { expression } }: EquationArgs) => {
type EquationProps = EquationArgs & { inline?: boolean };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

p3;
The need for additional props like 'inline' signals a potential for expanding requirements for the TeX component. Rather than limiting props, it appears more beneficial to allow users to handle TeX more freely while providing sensible defaults. This approach gives users the flexibility to extend the component's functionality as their requirements evolve, while maintaining a solid foundation of default behavior.

This pattern aligns better with the principle of extensibility and follows the "open for extension, closed for modification" design principle. By exposing the full capabilities of the underlying TeX component, we empower users to adapt the component to their specific needs without requiring changes to the core implementation.

import TeX from '@matejmazur/react-katex';
import type { TeXProps } from '@matejmazur/react-katex';

const Equation = ({
  className = '',
  ...props
}: TeXProps) => {
  return (
    <TeX
      className={`notion-block notion-equation ${
        !props.block ? "notion-equation-inline" : "notion-equation-block"
      } ${className}`}
      {...props}
    />
  );
};

export default Equation;

// example
// <Equation block={false}>E = mc^2</Equation>

Benefits of change

Enhanced Type Safety

Direct usage of TeXProps type fully leverages the TeX library's type system
Prevents incorrect props passing at compile time
Provides better TypeScript IntelliSense support

Improved Maintainability

Automatically supports new props when the TeX component is updated
Reduces code overhead by eliminating custom type definitions and prop mappings
Easier to track changes from the underlying library

Better Developer Experience

Full access to all TeX component features (settings, error handling, etc.)
Seamless migration path from existing TeX documentation and code examples
Consistent API with the original library

Styling Flexibility

Composable className prop that merges with default styles
Provides ability to override default styles when needed
Maintains consistent styling structure

Style Customization

Review the hardcoded notion-related classes - may need to make them configurable
Consider implementing a theme provider for global style settings

@anonymousRecords anonymousRecords marked this pull request as draft February 23, 2025 10:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants