Страница:
Design Goals
Страницы
API Deprecation
API Type Validation
API reports and review
Branches, Versions, and Releases
Breaking vs Non breaking Changes
Building documentation locally
Bundle Size Test
CI Pipelines
CLA
Changesets FAQ
Changesets
Checking for broken links in the documentation
Client
Coding Guidelines
Commit message style
Communicating breaking changes
Community Calls
Compatibility and Versioning
Contributing
Debugging
Design Goals
Dev Tools Maintenance
Documentation Dos and Don'ts
Documentation guidelines
Documenting JavaScript
Documenting TypeScript
ESLint
Fluid Terminology
Home
Maintaining API support levels
Managing dependencies
Markdown Best Practices
PR Guidelines
PR review process
Release Tags
Release notes 2.0.0 internal.3.0.0
Repo Basics
Server
SharedTree
Submitting Bugs and Feature Requests
TSDoc Guidelines
Testing
Upcoming change‐‐The build task will no longer run formatting and check tasks
Updating code using legacy Fluid APIs
Uploading images for the website to Azure blob storage
Website PR validation
Where To Put Documentation
Working with the Website
npm package scopes
pnpm tips and tricks
5
Design Goals
Sam Broner редактировал(а) эту страницу 2020-06-18 11:45:14 -07:00
Содержание
Introduction
This page describes the general design goals of the Fluid Framework. Its purpose is to provide some background on certain design decisions and describe the general thinking for the codebase. It is by no means definitive or exhaustive. Each part of the Fluid Framework, client components, distributed data structures (DDSs), hosts & loaders, back-end servers, etc. each deserve their own design-goals document. These are, however, good general guidelines to have in mind and consider while introducing any changes.
Goals
- Create modular, reusable pieces of client component code that update in a synced, real-time manner
- Be platform agnostic. Fluid Framework should work with any data storage provider, rendering framework, and platform.
- Have an extremely lightweight, easy-to-deploy backend server to relay messages amongst clients
- Handle all ordering logic for real-time functionality on individual clients, not the server
- Abstract complex real-time logic from client view code using generic, multi-purpose DDSs
- Define clean interfaces for components to interact among one another, and respect component logic abstraction. A component should not refer to another component's inner DDSs.
- Be easy to develop on. Onboarding to Fluid should require minimal initial setup, and tooling should be available to readily create new components.
Overview
Contributing
- Submitting Bugs and Feature Requests
- Contributing to the Repo
- Repo Basics
- Common Workflows and Patterns
- Managing dependencies
- Client Code
- Server Code
- PR Guidelines
- CI Pipelines
- Breaking vs Non-Breaking Changes
- Branches, Versions, and Releases
- Compatibility & Versioning
- Testing
- Debugging
- npm package scopes
- Maintaining API support levels
- Developer Tooling Maintenance
- API Deprecation
- Working with the Website (fluidframework.com)
- Coding Guidelines
- Documentation Guidelines
- CLA
Using Fluid Framework
This wiki is focused on contributing to the Fluid Framework codebase.
For information on using Fluid Framework or building applications on it, please refer to fluidframework.com.