GraphQL Fragments: ಪ್ರತಿಯೊಂದು ಘಟಕವು (Component) ತನ್ನ ಡೇಟಾವನ್ನು ತಾನೇ ಹೊಂದಿರಲಿ

GraphQL ಕ್ವೇರಿಗಳು ಮೊದಲ ನೋಟಕ್ಕೆ ಸ್ವಚ್ಛವಾಗಿ ಕಾಣುತ್ತವೆ. ಒಂದು ವಿನಂತಿಯು (request) ನಿಮ್ಮ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ. ನಂತರ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬೆಳೆಯುತ್ತದೆ.

ನಿಮ್ಮ ಪೇಜ್ ಕ್ವೇರಿಯು ಅನೇಕ ವಿಭಿನ್ನ ಚೈಲ್ಡ್ ಘಟಕಗಳಿಗಾಗಿ (child components) ಫೀಲ್ಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ನೀವು ಹೊಸ ಘಟಕಕ್ಕಾಗಿ ಒಂದು ಫೀಲ್ಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಆರು ವಾರಗಳ ನಂತರ ನೀವು ಆ ಘಟಕವನ್ನು ಅಳಿಸಿవేಸುತ್ತೀರಿ. ಆದರೆ ಮುಖ್ಯ ಕ್ವೇರಿಯಿಂದ ಆ ಫೀಲ್ಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲು ನೀವು ಮರೆಯುತ್ತೀರಿ. ಈಗ ಅದನ್ನು ಅಳಿಸುವುದು ಸುರಕ್ಷಿತವೇ ಎಂದು ಯಾರಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ. ಕ್ವೇರಿಯು ಸತತವಾಗಿ ಬೆಳೆಯುತ್ತಲೇ ಹೋಗುತ್ತದೆ.

Fragments ಇದನ್ನು ಸರಿಪಡಿಸುತ್ತವೆ. ಹೆಚ್ಚಿನ ತಂಡಗಳು ಫೀಲ್ಡ್‌ಗಳನ್ನು ಕಾಪಿ ಮತ್ತು ಪೇಸ್ಟ್ ಮಾಡಲು ಇವುಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಇದು ತಪ್ಪು ವಿಧಾನ. Fragments ಎಂಬುದು ಘಟಕದ ಮಾಲೀಕತ್ವದ (component ownership) ಮಾದರಿಯಾಗಿರಬೇಕು.

Fragment ಎಂಬುದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಟೈಪ್‌ಗಾಗಿ (type) ಹೆಸರಿಸಲಾದ ಫೀಲ್ಡ್‌ಗಳ ಗುಂಪು.

ಉದಾಹರಣೆ:

fragment UserBadge on User {
  id
  name
  avatarUrl
}

User ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಕ್ವೇರಿಗೆ ನೀವು ಈ ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು spread ಮಾಡಬಹುದು.

ಇದರ ನಿಜವಾದ ಮೌಲ್ಯವು ನೀವು ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಎಲ್ಲಿ ಉಳಿಸುತ್ತೀರಿ ಎಂಬುದರಲ್ಲಿದೆ. ಅವುಗಳನ್ನು ಹಂಚಿಕೆಯ ಫೈಲ್‌ನಲ್ಲಿ (shared file) ಇಡಬೇಡಿ. ಅದನ್ನು ಬಳಸುವ ಘಟಕದ (component) ಅದೇ ಫೈಲ್‌ನಲ್ಲಿ ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಇರಿಸಿ.

ಇದನ್ನು co-location ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಘಟಕವು ತನ್ನದೇ ಆದ ಡೇಟಾ ಅಗತ್ಯಗಳನ್ನು ಘೋಷಿಸುತ್ತದೆ.

ಒಂದು ಘಟಕಕ್ಕೆ ಹೊಸ ಫೀಲ್ಡ್ ಅಗತ್ಯವಿದ್ದಾಗ, ನೀವು ಅದನ್ನು ಅದರ ಫ್ರಾಗ್ಮೆಂಟ್‌ಗೆ ಸೇರಿಸುತ್ತೀರಿ. ಪೇರೆಂಟ್ ಕ್ವೇರಿ (parent query) ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಪ್‌ಡೇಟ್ ಆಗುತ್ತದೆ. ನೀವು ಒಂದು ಘಟಕವನ್ನು ಅಳಿಸಿದಾಗ, ಅದರ ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಸಹ ಅಳಿಸಿవేಸುತ್ತೀರಿ. ಇದರಿಂದ ಕ್ವೇರಿಯ ಗಾತ್ರ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಪೇರೆಂಟ್ ಘಟಕವು ತನ್ನ ಚೈಲ್ಡ್ ಘಟಕಗಳ ಆಂತರಿಕ ಫೀಲ್ಡ್‌ಗಳ ಬಗ್ಗೆ ತಿಳಿಯುವ ಅಗತ್ಯವಿಲ್ಲ.

Data masking ಇದನ್ನು ಇನ್ನಷ್ಟು ಉತ್ತಮಗೊಳಿಸುತ್ತದೆ. Masking ಸಕ್ರಿಯಗೊಂಡಾಗ, ಒಂದು ಘಟಕವು ತನ್ನದೇ ಆದ ಫ್ರಾಗ್ಮೆಂಟ್‌ನಲ್ಲಿ ಕೇಳಿದ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಸರ್ವರ್ ಹೆಚ್ಚಿನ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಿದರೂ ಸಹ, ನಿಮ್ಮ ಘಟಕವು ಅದನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಇದು ಒಂದು ಕಟ್ಟುನಿಟ್ಟಾದ ಒಪ್ಪಂದವನ್ನು (strict contract) ಸೃಷ್ಟಿಸುತ್ತದೆ.

  • TypeScript ಪ್ರತಿಯೊಂದು ಘಟಕವು ಯಾವ ಡೇಟಾವನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಯುತ್ತದೆ.
  • ನೀವು ಫ್ರಾಗ್ಮೆಂಟ್‌ನಿಂದ ಒಂದು ಫೀಲ್ಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದರೆ, TypeScript ನಿಮಗೆ ಎಲ್ಲಾ ದೋಷಗಳನ್ನು (errors) ತೋರಿಸುತ್ತದೆ.
  • Refactoring ಎಂಬುದು ಇಡೀ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ಹುಡುಕುವ ಬದಲು ಸರಳವಾದ type-check ಆಗಿ ಬದಲಾಗುತ್ತದೆ.

ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ fragments ಬಳಸಿ:

  • ಅನೇಕ ಘಟಕಗಳು User ಅಥವಾ Product ನಂತಹ ಒಂದೇ ಟೈಪ್ ಅನ್ನು ಬಳಸಿದಾಗ.
  • ನಿಮ್ಮ ಪೇಜ್ ಕ್ವೇರಿಗಳು ತುಂಬಾ ಉದ್ದವಾಗಿದ್ದಾಗ.
  • ನೀವು ಅಚಾನಕ್ಕಾಗಿ ನಿಮ್ಮ ಕ್ವೇರಿಗಳಲ್ಲಿ ಬಳಕೆಯಿಲ್ಲದ (dead) ಫೀಲ್ಡ್‌ಗಳನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಾಗ.
  • ನಿಮ್ಮ ಡೇಟಾಕ್ಕಾಗಿ ನೀವು TypeScript ಸುರಕ್ಷತೆಯನ್ನು ಬಯಸಿದಾಗ.

ಸಣ್ಣದಾಗಿ ಪ್ರಾರಂಭಿಸಿ. ಪೇರೆಂಟ್ ಕ್ವೇರಿಯಿಂದ ಡೇಟಾವನ್ನು ಪಡೆಯುವ ಒಂದು ಘಟಕವನ್ನು ಹುಡುಕಿ. ಅದರ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಒಂದು ಫ್ರಾಗ್ಮೆಂಟ್‌ಗೆ ವರ್ಗಾಯಿಸಿ. ಆ ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಘಟಕದ ಫೈಲ್‌ನಲ್ಲೇ ಇರಿಸಿ.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬೆಳೆದಂತೆ, ನಿಮ್ಮ ಡೇಟಾ ಫೆಚಿಂಗ್ (data fetching) ನಿಮ್ಮ UI ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು Fragments ಖಚಿತಪಡಿಸುತ್ತದೆ.

Source: https://dev.to/grimicorn/graphql-fragments-let-each-component-own-its-data-5359