Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Change search pattern across the application

オープン
#2,239 コメント 6 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
javascript, rails, ruby
領域
backend, database, frontend

調査の方向性

まず、ワークショップに人を直接追加するための管理フローを追跡します。これには、読み込まれた Member レコードに対する現在の JavaScript によるフィルタリングと、データベースクエリの経路が含まれます。実装を選択する前に、検索フォームと結果選択の動作を定義します。完了条件は、管理者が少数の結果セットを検索し、フロントエンドに何百件ものレコードを読み込まずに、選択した人物に対して操作できることです。

索引モデルが issue の本文から書いたものです。

説明

Proposal

We should switch to a more traditional search pattern, where a user fills in a search form, the application queries the database, and returns a small set of results for the user to then take action against. For example, when directly adding people to a workshop, the admin would type a name into a search bar. They click 'search' and receive a list (or possibly just one) result. They click on the result and then take action.

Why this?

The application was originally built without realising how massive our chapters would get. As a result, we load hundreds of Member records into the frontend, and then filter them using javascript. This slows the application down and makes it really difficult to use for admins.

Why now?

We've got a small team set up around maintenance, and this would be a significant quality of life improvement.

主要言語
Ruby
スター
104
フォーク
205
平均マージ
1日 8時間
マージ済み PR（30日）
67

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

codebar/planner のほかの issue

codebar/planner の issue をすべて見る

似ている issue

Ruby の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。