PaperMC / PaperMC/docs

Conceptual overview of chat components

Open
#663 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

dev guide meta guide project: Adventure
Dominant language
MDX
Stars
73
Forks
280
Avg merge
20h 52m
Merged PRs (30d)
4

Description

It seems like there is a big gap in understanding with a lot of users new to adventure, who have trouble with the concepts of chat components, having only been familiar with the legacy section-symbol system. It would be helpful to explain what components are and some of their key characteristics, ideally with some graphics. Here's a rough outline of what I'm imagining:

  1. What is a component?
    1. structured representation: the text form represents the data structure, rather than being marked-up text
    2. different types of content
    3. tree structure: see style
    4. appending: children in the tree (visual here?)
  2. Where did components come from?/Why do we want to use components?
    1. history: 1.7.2 introduction, 1.13 most of the server converted to use them, 1.16 client text renderer converted
    2. originally: a way to be more explicit about links and other rich styling
    3. references:
    4. examples of quirks/limitations of legacy text, and how chat components resolve those issues
  3. Style in components
    1. tree style
    • [visual] show a component tree with styles, show how they're inherited, and piecewise overridden
    1. attributes can exist together, no 'magical' reseting like legacy strings had
    2. more attributes can be added -- see font or RGB colour
  4. Examples
    1. Some side-by-side tables of json, adventure representation, and in-game visuals?
  5. History of components (can it be merged with 2?)
    1. version-by-version breakdown of what has been added/changed

Migrated from https://github.com/KyoriPowered/adventure-docs/issues/49

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No target file or test is named. Start with the proposed outline and its linked component-history references; done means a published conceptual overview explaining components, styling, history, and examples with the suggested graphics or comparisons.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.