Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(views): let a view declare a display name — the page chooser can only print the view id

Open
  • Is something wrong?
#79 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
typescript
Domain
backend-api-design

Research direction

Start by reading dist/appViews.js:26 and dist/appViews.js:62-70 to trace the view declaration constraints and normalized keys. Check how protocol versions and the public, member, and participant tiers are handled, including legacy public.view. Done means the declaration shape and compatibility decisions are settled for this repository, with the separate mulmoserver rendering change clearly scoped.

Written by the indexing model from the issue text.

Description

enhancement

背景

member ページを2枚以上宣言すると /m/<slug> はページの選択画面になる。そこに並ぶのは view の id そのもので、利用者に見せる名前を指定する手段がない。

正規化後の view が運ぶキーは次のとおりで、title 相当が無い（dist/appViews.js:62-70、0.35.0）。

id / audience / path / article / collections / live / limit / where

id は dist/appViews.js:26 の VIEW_ID_PATTERN（^[a-z0-9][a-z0-9-]{0,63}$）に制限されるため、日本語のアプリでもこの一覧だけが英字の識別子になる。

描画側は receptron/mulmoserver の src/views/MemberApp.vue（main ブランチで確認）で、ページ一覧が {{ view.id }}、同じ画面に続くレコード一覧が {{ cid }} を出している。どちらも表示名を探す処理は無い。

この issue の範囲

このリポジトリで決めるのは宣言の形（view に表示名を持たせるか、どのキーで）だけである。描画側の変更は mulmoserver に別途出す。下の「レコード一覧」の話は同じ画面に見えるが別の要望なので、ここでは触れるに留める。

なぜ困るか

ページが2枚以上ある共有アプリでは、利用者が必ずこの画面を通る。回避策は各ページの直リンク（/m/<slug>/<id>）を配ることだが、これは選択画面を使わせないという回避であって、画面自体は残る。

id を読みやすくする方向にも限界がある。文書 ID でもあるため綴りの自由度が低く、たとえば記録用のページに record を当てると、同じ画面のすぐ下に並ぶ records コレクションと1文字違いになる。

決める必要がありそうな点

実装を提案する前に、次が決まっていないと形が定まらないと思われます。

  • 追加が minor なのか、protocol を上げる必要があるのか（古い reader が未知キーを無視して従来どおり描ければ前者と推測しますが、未確認です）
  • public / member / participant の全 tier で同じ扱いにするか
  • 旧形式の public.view にも許すか

考えられるアプローチ

1つ目がこの issue の対応で、2つ目は別の要望です（同じ画面に並ぶので言及だけしています）。

  • view 宣言に任意の title を足し、選択画面がそれを使う（無ければ従来どおり id）というのはどうでしょうか。id は文書 ID なので制約は変えずに済みます
  • レコード一覧のほうは、schema が既に持っている title を使えば新しいキーを増やさずに済みそうです（ただし schema の title を member 層の投影が運んでいるかは未確認です）
  • 宣言の形はこのリポジトリ、描画は mulmoserver 側なので、いずれも2リポジトリにまたがる変更になります

環境

  • @receptron/sharedapp 0.35.0（mulmoterminal 4.14.0 の同梱版。receptron/mulmoserver main 1d703d9 の依存も ^0.35.0）で確認。dist/appViews.js の view 宣言のキーは 0.34.0 と同じで、title は無い
Dominant language
TypeScript
Stars
1
Forks
0
Avg merge
13m
Merged PRs (30d)
10

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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.

More from receptron/sharedapp

All issues in receptron/sharedapp

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.