솔리더스 어드민랜드
이는 알파 이전 단계이므로 향후 변경될 수 있습니다.
이것은 solidus_backend 관리 패널의 보다 안정적인 버전을 만들기 위한 내부 목적을 위한 재미있는 프로젝트로 시작됩니다. Solidus는 훌륭한 핵심 구성 요소와 배터리 포함 관리 인터페이스를 가지고 있지만, 우리 의견과 사용자 정의로 인해 관리 gem은 solidus_core 구조와 통신하기 위한 실제 측면 인프라가 되기 위한 디자인 구조가 부족합니다.
특징
- 아름답고 사용하기 쉬움(UX 중요)
- Hotwire 터보 구동 ⚡️
- 작은 반짝임에 대한 가져오기 맵으로 자극
- Ransack으로 필터링이 쉬워졌습니다
- 파괴와 같은 일괄 작업
바퀴를 다시 쓰는 이유는 무엇입니까?
말했듯이, 우리 의견으로는 solidus_backend는 다시 선택하게 된 라이브러리에 갇히게 되는 많은 경고를 전달하며(Deface, 나는 당신을 보고 있습니다!) 이 stucure는 그러한 선택에 너무 엄격합니다.
- Ransack이 포함된 필터 중 상당수가 맞춤 매개변수 다이제스트로 인해 지저분해졌습니다.
- Cancan은 실제 CRUD 경로가 아닌 '매크로'(:manage, :admin)와 함께 사용할 수 있으며 MVC 패턴 규칙을 따르지 않습니다.
- 제품, 주문 및 판촉 편집은 기존 CRUD 동작이 아닌 백본이 있는 Ajax에 의존합니다.
- "실제로" 터보 호환되지 않음: Turbolinks는 핫와이어에서 발전했으며 현재 사용법은 javascript 올바른 스크립트 실행을 위한 단편일 뿐입니다.
- 터보를 사용하여 보다 깨끗하고 예측 가능한 HTML 응답 대신 Rails-ujs 및 'remote: true'의 자바스크립트 원격 실행을 많이 사용합니다. 나는 원격이 실행되기를 바라면서 브라우저 콘솔에 자바스크립트 코드를 삽입하고 나에게는 크로스 스크립팅 잠재적인 보안 위협이기 때문에 좋은 접근 방식이 아니라고 생각합니다.
보시다시피, solidus_admin은 꽤 오래되었으며 solidus_starter_frontend를 사용한 solidus_frontend 개편의 경우 이제 대대적인 실험과 갱신이 필요한 시간입니다!
새로운 solidus_backend gem을 생성하려고 하시나요?
일종의 그러나 아니요 . 우선 이 프로젝트를 대체 프로젝트로 시작하겠습니다. 왜냐하면 이 프로젝트는 알파 프로젝트이고 레일 프레임워크와의 결합이 낮은 배터리 포함 백엔드와 함께 확장성과 헤드데클 없이 UI 사용자 정의를 위한 꽤 구조화된 Adminland 프레임워크를 함께 제공하는 것이 목표이기 때문입니다. . 나는 너무 엄격하지 않고 쉽게 통합할 수 있도록 호스트 프로젝트의 소유자가 선택한 라이브러리에 더 의존하게 만들고 싶습니다.
좋아, 그럼 당신의 선택은 무엇입니까? 당신도 의견이 있는 편인가요?
나는 우리가 이 기본 사항을 반영하기 위해 관리 코드 구조를 생각할 수 있다고 생각합니다.
- 재정의가 쉽고 재정의/원숭이 패치 접근 방식을 줄여 확장할 수 있습니다. 우리는 원숭이가 아니라 인간입니다!
- Deface에 대한 사전 금지. 나는 훼손 접근 방식을 결코 좋아하지 않았으며 처음부터 UI를 모듈식으로 생각하는 것이 더 낫다고 생각합니다. 대안으로 패치 및 주입이 아닌 복사로 뷰를 재정의하는 것입니다. 다른 사이드카 도구(관리 섹션이 있는 모든 solidus 확장)의 확장성을 위해 나는 더 명확하고 노출된 앞에 추가 지점을 만드는 것을 선호합니다.
- CRUD 경로에 엄격합니다. 모든 것은 구성 접근 방식보다 규칙을 선호하는 중첩 경로 접근 방식과 마찬가지로 가능한 한 엄격한 CRUD 경로에 의존해야 합니다.
- 생성기 스캐폴드 템플릿을 사용하여 호스팅 레일 앱에서 외부 리소스를 추가해야 합니다.
이를 염두에 두고 '새로운' solidus_adminland 프로젝트에 대해 다음과 같은 몇 가지 선택을 하기 시작했습니다.
- 기본적으로 핫와이어를 사용하고 js DOM 조작 접근 방식 이상의 것을 권장합니다.
- 선택기, 입력 마스크 및 양식 검증과 같은 간단하고 안정적인 추가를 위한 자극
- HTML 결과(예: 더 복잡한 결과에 대한 link_to)를 캡슐화하는 도우미 메서드에 view_comComponent gem을 사용합니다. 안정성을 위한 부분 및 UI 로직을 위한 PORO 클래스 대신 재정의 목적으로도 더 쉽습니다.
- 모든 자산 가져오기는 '자바스크립트 중심 앱 접근 방식 없음'을 위해 Rails-importmap을 사용하여 이루어집니다.
- 표현(*Dashboard 클래스 사용)과 데이터를 표시하거나 제출하기 위한 CRUD 경로 간의 우려 사항을 구분하기 위해 관리 gem을 사용합니다.
- 모든 양식은 모든 필드가 분리된 Component 클래스로 렌더링되는 FormBuilder에 의해 스타일이 지정됩니다. 기능에 Dropdown JS 필드와 같은 이상한 필드를 추가하려는 경우 새로운 Admininstrate::Field, FormBuilder::Component 및 js 스파클에 대한 자극을 사용하여 만들 수 있습니까?
- 정책적 측면에서는 캉캉과 양립하면서도 좀 더 쉬운 푸디트 접근 방식을 취하는 하이브리드 접근 방식을 만들 수 있다고 생각합니다. 우리의 경우에는 action_policy gem을 사용합니다. 이는 각 작업에 대해 진행 규칙이 무엇인지 정의할 수 있는 PORO 개체에 의존합니다. 이는 '기록 범위', '허용된 매개변수 기록' 및 '접근 가능한 경로 기록'에 대한 제어 정책을 위한 컨트롤러의 실제 중간 부분입니다.
보시다시피 모든 리소스에는 다음이 있습니다.
- 표준 CRUD 작업에 대해 동일한 이름을 가진 컨트롤러
- 표시할 index, new_form, edit_form 및 show 매개변수에 대해 동일한 이름을 가진 대시보드
- 현재 사용자가 액세스할 수 있는 범위, 내가 제출할 수 있는 매개변수 및 해당 리소스에 대해 허용되는 경로에 대한 정책입니다.
... 그리고 '기존' 접근 방식으로 이 세 가지 중 직접 생성(또는 확장)하고 원하는 대로(또는 앱에서 요구하는 대로) 비즈니스 로직을 추가할 수 있습니다!
초기 디자인은 Tabler를 사용하여 부트스트랩 5로 만들어졌지만 CRUD에 대한 관리/응용 프로그램의 표준 보기를 쉽게 재정의할 수 있습니다. 조회수는 가능한 한 낮게 유지됩니다.
로드맵
로고와 색상의 모든 권리는 solidus presskit에서 얻습니다. 관리 테마는 solidus 웹사이트 모형에서 영감을 얻었으며 Bootstrap 5 버전의 Tabler를 기반으로 합니다.