but: django was built to generate html, ... as the main thing, then with that tightly integrates API creation, DB access, ... -> we're probably looking into separating into a clean frontened for View and a clean backend for backend things

fastapi also generates OpenAPI specs by default, they use an additional tool (DRF spectacular) for that to work for django

experience is a bit weird, table _feels_ virtual, I get weird top and bottom artifacts (note emty rows, scrolling is a bit laggy with 1000 rows):

⁠

app is SSR, maybe part of problems one can see?

i don’t know why, but refresh forces logout?

ui:

relies heavily on scss - might be my inexperience with it, but it seems quite cumbersome, looking at the assice amount of scss files, that are also quite far from the templates that use them

some component are self defined, with logic, that probably should just be library imports, e.g.,

the Copied template⁠

contains a nice show hide logic gem

in general it seems like there is really funky things going on, most of which I would at least call “special”:

heavy use of mixins

heavy use of filters

custom directives to prevent scrolling

custom tooltip/toast/... directives and components that seem very complex and questionable why self written,

see here for a taste⁠

⁠

manual style guide implementation⁠

(yes, this is also a vue template inside the codebase that has a copy and paste of all components, at least if the maintaner managed to keep it up to date), something one resorts to if they don’t know storybook

it seems that he has created the table himself!

Every type has its own template, or “View” as he calls it. They are in view/grid, e.g.: GridViewFieldNumber, GridViewFieldSelect, ...

also cannot find any “helpers” for that inside package.json...

if this is true, I think the development effort on an integrated table is unsustainable - counterpoint: Is a good table a “solved” problem?

technical questions:

how is user management implemented? → django + self

totally self implemented with deep integrations into django

e.g., during user creation:

⁠

UserView offers registration _logic_⁠

⁠

In term invokes a core.user.handler.UserHandler to then

get a django UserModel via get_user_model

to then filter all users to check if email or username exists via django ORM style user access

to then create the user via some django functions (User constructor, set_password (which likely takes care of hashing, ...), .save)

seems a bit foolish to implement all this yourself, but we’ve done this ourself once as well: craft innovation + strapi

counterpoint: Is a single standing user management system a “solved” problem?

problems arising here: this deep integration makes it hard to modify the code substantially without working in the same django ecosystem (learning, understanding it, writing django)

how to change the landingpage/layout? → okayish

see bad practices section in `misc` above for a disclaimer, that said: should be possible, as it does not touch any deep logic/implementations

but, we will be forced heavily to stay within his implementations

how hard is it to add tags to this implementation? → hard

before starting this research, there was a clear answer in my mind: easily

now, not so much: To add tags, we’d have to adapt the backend plus the custom table implementation

the way that they have currently developed this, it is very hard to change this and make sure (without them looking at it), that it actually works

as a blueprint for just the cell frontend component we’d have to write (and then register in 3 central places, understand all the scss he’s written so far, ...) can be found here:

the implementation of a boolean cell⁠

, look at:

custom document.body event handlers

listening for keyCode 13 (enter),

which is deprecated⁠

(note, that similar code is duplicated accross 7 different files, which makes the code un-maintainable in and of itself: what if we need to additionally check something else, e.g., we want to switch to Cmd + Enter? then all 7 places need to be changed, and then we need to check for Cmd and Ctrl, as we have windows and mac users)

opaque mixins

same and additional complexioty arises taking the backend into account

now the answer is: hard

global search/multi file upload → hard

see previous answer: as all of this is one custom implementation, it becomes pretty hard to understand where logic is spread, thus making this hard

user permissions on row/cell levels → easy with hack, hard to do it right

see above points on user management (for backend context) and “tags” implentation (for frontend context): we will have to deeply commit and understand to their implementation. Having row/cell based permissions working with the frontend will depend very much on how easy it is to adapt their individual cell implementations

here I see bigger questionmarks in the backend, the frontend could support an implementation where we ignore the UI (and UX?) by just adding a “block” to the centralized store, that stops a value update last second and gives the user a notification that they are not allowed to edit it

for the backend we would have to get into django though, as it stands between us, the database and the user management

Found a guide on how to implement your own field type:

https://gitlab.com/bramw/baserow/-/blob/develop/docs/plugins/field-type.md⁠

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.