Coder Social home page Coder Social logo

pleisto / mashcard Goto Github PK

View Code? Open in Web Editor NEW
210.0 32.0 36.0 155.93 MB

An open-source web-based OS and no-code PaaS to boost productivity.

Home Page: https://www.producthunt.com/upcoming/brickdoc

License: Apache License 2.0

Shell 0.01% Dockerfile 0.12% JavaScript 0.58% TypeScript 82.99% Ruby 15.14% HTML 0.11% Rust 0.94% CSS 0.01% Smarty 0.10%
editor graphql rails react formula nocode notion-alternative rust coda-alternative monorepo

mashcard's People

Contributors

0xding avatar aligo avatar darmody avatar dependabot[bot] avatar github-actions[bot] avatar melchior-voidwolf avatar moyilong avatar stackia avatar toadfansboy avatar z4cki avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mashcard's Issues

Remove `currentPod` in `Current` module

Move username to arguments

Todo list:

  • blockCreate, BlockPinOrUnpin, BlockCommit #425
  • GroupUpdateMember, PodMembers #431
  • ActiveStorage and CreateDirectUpload #441
  • BlockSyncBatch
  • BlockPins
  • ChildrenBlocks
  • DocumentInfo
  • cleanup user.rb: fetch_current_pod_cache, current_pod_id, current_pod_cache, guess_pod
  • cleanup current_pod.rb CurrentPod module
  • cleanup specs

Reorganising the folder structure of PWA

Background

We currently use an angular-style Folder-by-Feature structure for PWA, but there is a lack of consistent convention for the boundaries and granularity of features. So there is a lot of room for improvement.

Folder Page

Background

We use a compound document structure that supports the inclusion of sub-pages within any page block, so there is no need real concept of folders. However, based on the user's mental model, we may want to making sub-page blocks look more like folders when they are presented on the parent page.

Design

Figma link

Goals

  • Those pages containing sub-pages that do not have an icon set by the user will use the folder icon by default.
  • Those pages containing sub-pages will display a list of sub-pages at the bottom of the page like a MacOS Finder.

Removes source field

The source field is used to distinguish whether a file comes from uploading or an external link. Because we need to do some tricks on getting the uploaded file's URL. It is no need to do that now, we can get the uploaded file's URL directly and remove this field on every file-related attributes object.

For Example:

https://github.com/mashcard/mashcard/blob/main/packages/brickdoc-editor/src/extensions/blocks/embed/meta.ts#L77
https://github.com/mashcard/mashcard/blob/main/apps/client-web/src/BrickdocGraphQL.ts#L156

export type BlockAttachment = {
  ...
  /** source */
  source?: Maybe<FileSource>
  ...
}

Add placeholder texts for new blank blocks (e.g. h1/h2/etc.)

image

Currently, when we create a new h1 block, there is no text displayed.

We should provide a 'Heading 1' placeholder text here.

A list of all placeholder designs:

Block Link
H1 https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
H2 https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
H3 https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
H4 https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
H5 https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
Body https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
Unorder list https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
numbered list https://www.figma.com/file/RyaabEPkCD9l72OwwcNeSl/Web-UI---C-Page?node-id=6325%3A217484
img/local file https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=1949%3A53234
formula https://www.figma.com/file/eeb1ZIE2L16M24mEDhNTML/Web-UI---E-Formula?node-id=4318%3A133804
Spreadsheet https://www.figma.com/file/kevJMlw2M1379xodbk3NWJ/Extension-UI?node-id=1474%3A46904
link https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=7543%3A117577
code https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=4614%3A158131
unsplash https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=7543%3A117995
media https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=7576%3A117777
todo list https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=6735%3A128733
callout https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=6716%3A125184
pdf https://www.figma.com/file/pKCVegQsV7NqwMfhapeWmR/Web-UI---G-Embed?node-id=1949%3A53234

GPT3 formula plugin

Use case

  • tl;dr: formula for automatic text summarization;
  • Natural language to formula expression;

Separating the concerns of PWA and Monolith Server

Background

Our application consists mainly of PWA and Monolith Server. Since http-only cookies are the only truly secure way to store user authentication credentials in the browser, we currently use a monolith server mounting PWA entrypoint and use cookies to authenticate GraphQL API requests.

As we may package PWA as a desktop app in the future, we need to refactor it to separating the concerns of PWA and Monolith Server.

Goals

  • Split user authentication and API authentication;
  • Use GraphQL query to instead of globalThis.brickdocContext to access metadata;
  • Render and serve PWA entrypoint page using a static web server (To be discussed);
  • Admin panel should be part of monolith server;

Solution

Internal Note: Our private monorepo has a PoC implementation of this refactor, which is available here.

We could use inertia.js to build fullstack features with React.js. And use doorkeeper-oidc to implement API authentication logic.

user authentication related features such as sign up, forgot password are implemented in the monolith server by inertia.js. PWA will be focused on the user facing features, and use PKCE flow to authenticate API requests. (The token needs to be stored in memory only, and remember-me will be transparently implemented in the monolith server via a cookie.)

create BubbleMenu extension

BubbleMenu extension exists in the BubbleMenu component currently. Move it out to make it configurable in an extension be-like way.

Refactor accounts and pod model

Background

The accounts and pod models in this codebase are still legacy versions and need to be migrated to our new design ASAP to avoid schema changes in the future.

Goals

  • Using Pod as a unique tenant modal, user and group is essentially a type of pod;
  • Migrate configuration fields like invite_enabled to BrickdocConfig model;
  • Rename Accounts::Member to Groups::Member to ensure correct semantics;
  • Remove Accounts:: prefix from all models;
  • Remove owner attribute from Pod model. Use Group::Member instead to simplify;

Solution

User and Group are the two types of pods, and they are inherited from Pod model and share the same database table (STI).

The logic for authentication is implemented in the Users::Authentication model, which is one-to-one relation with the User model. And, features specific to group pods like inviting members are implemented in Group model instead of Pod model.

Internal Note: Our private monorepo has a PoC implementation of this refactor, which is available here.

Schemas

  create_enum "pod_type", ["User", "Group"]
  create_table "pods", force: :cascade do |t|
    # remove t.bigint "owner_id", null: false
    t.string "username", null: false # domain --> username
    t.string "display_name", null: false # name --> display_name
    t.string "bio", limit: 140, comment: "\"Bio\" means Biography in social media."
    # remove: t.boolean "personal", default: false, null: false
    t.datetime "deleted_at"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    # remove: t.boolean "invite_enable", default: false, null: false
    # remove: t.string "invite_secret"
    t.index "lower((domain)::text)", name: "index_pods_on_lower_domain_text", unique: true
    t.index ["deleted_at"], name: "index_pods_on_deleted_at"
    # remove: invite_secret could store in redis.
    # remove: t.index ["invite_secret"], name: "index_pods_on_invite_secret", unique: true
    t.index ["owner_id"], name: "index_pods_on_owner_id"

    # new fields
    t.datetime "suspended_at", comment: "the date when the user was suspended"
    t.integer "suspended_reason", default: 0, comment: "enumeration value for the reason for the user suspension"
    t.string "external_avatar_url"
    t.string "last_pod_username" # migrate from `accounts_users`
    t.string "last_block_ids", default: "{}", null: false # migrate from `accounts_users`
  end

  create_table "users_authentications", force: :cascade do |t|
    t.belongs_to "user", null: false, foreign_key: { to_table: "pods" }
    t.string "email"
    t.string "encrypted_password", default: "", null: false
    t.string "reset_password_token"
    t.datetime "reset_password_sent_at"
    t.datetime "remember_created_at"
    t.integer "sign_in_count", default: 0, null: false
    t.datetime "current_sign_in_at"
    t.datetime "last_sign_in_at"
    t.string "current_sign_in_ip"
    t.string "last_sign_in_ip"
    t.string "confirmation_token"
    t.datetime "confirmed_at"
    t.datetime "confirmation_sent_at"
    t.string "unconfirmed_email"
    t.integer "failed_attempts", default: 0, null: false
    t.string "unlock_token"
    t.datetime "locked_at"
    t.datetime "deleted_at"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.index ["confirmation_token"], unique: true
    t.index ["deleted_at"]
    t.index ["email"], unique: true
    t.index ["reset_password_token"], unique: true
    t.index ["unlock_token"], unique: true
  end

It is important to note that although the above schema appears to rename accounts_users to users_authentications, they have completely different semantics. The Users::Authentication model is only responsible for authentication, and the User model inheriting from Pod model being responsible for user information. Theoretically, once the user has logged in, the Users::Authentication is no longer needed.

Model

class Pod < ApplicationRecord
end

class User  < Pod
  has_one :authentication, class_name: "Users::Authentication"
  has_one :pod, class_name: "Pod", foreign_key: "id"
  has_many :group_members, class_name: "Groups::Member", dependent: :destroy
  has_many :groups, through: :group_members
  has_many :owned_groups,
    # don't destroy the user if it is owner of a group
    -> { where(role: :owner) }, through: :group_members, source: :group, dependent: :restrict_with_exception
end

class Group < Pod
  has_many :members, class_name: "Group::Member"
  has_many :members, class_name: 'Groups::Member', dependent: :destroy
  has_many :users, through: :members
  has_one :owner, -> { where(role: :owner) }, through: :members, source: :user
end

module Groups
  class Member < ApplicationRecord
    belongs_to :group, class_name: 'Group', inverse_of: :members
    belongs_to :user, class_name: 'User', inverse_of: :group_members

    ROLES = {
      owner: 0,
      member: 1,
    }
    enum role: ROLES
  end
end

adds i18n feature to editor

currently, the editor's i18n depends on the client-web app, it should be set up in the editor. And the editor should also have the ability to customize i18n.

Removes implicit dependency of @brickdoc/schema in editor

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.