Delete vestigial MailingListForm; use button_to for subscribe/unsubscribe
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 88/100
Hướng nghiên cứu
Trước tiên, hãy đọc app/views/subscriptions/index.html.haml và app/form_models/mailing_list_form.rb, sau đó kiểm tra phần coverage của trang subscriptions trong spec/features. Xác nhận các route Create và Destroy hiện có cùng các action của MailingListsController trước khi thay đổi view. Công việc được xem là hoàn tất khi cả hai button hoạt động giống nhau, unsubscribe vẫn sử dụng DELETE, form model đã được xóa và các feature spec liên quan đều pass.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
app/form_models/mailing_list_form.rb is a one-line ActiveModel::Model class (attr_accessor :name) that exists only as an anchor object for two simple_form_for wrappers in app/views/subscriptions/index.html.haml. Those "forms" are just subscribe/unsubscribe buttons — no fields are rendered, and MailingListsController ignores all params (its create/destroy read nothing). TermsAndConditionsForm stays — it has a real acceptance validation and .valid? gate.
Proposed change
- Replace both
simple_form_for @mailing_list, ...wrappers withbutton_to(native Rails: handles POST/method: :delete, CSRF, and accepts the sameclass: 'btn btn-success btn-lg mb-0'). - Delete
app/form_models/mailing_list_form.rb. - No controller or route changes.
Acceptance
- Subscribe/unsubscribe buttons on the subscriptions page behave identically (including
method: :deletefor unsubscribe). MailingListFormno longer exists.spec/featurescovering the subscriptions page pass.
- Ngôn ngữ chính
- Ruby
- Star
- 104
- Fork
- 205
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 81
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của codebar/planner
-
performance
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue refactoring tech debt
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue tech debt
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Chapter show pages allocate ~21k+ objects per render for large chapters (18% of app allocations)Đang mởperformance
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của codebar/planner
Issue tương tự
-
area/web interface
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
chef/mixlib-shellout#287 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày