You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently refactored the codebase to abstract objects and fields, both on the frontend and on the backend.
We now have a standardized way to create a objects, it's much faster to introduce new standard objects and user can even create their own custom objects.
But we lost some flexibility in the way. Because those concepts have been abstracted, it's now harder to have a particular behavior for a particular object. For example we might want to have a middleware for companies on the backend that transforms data upon creation (enrichment). Or on the frontend, we might want to have a specific layout - such as showing the employees on the companies object in a different way than we show other "related objects".
This issue is only about the frontend side, the goal is to create a framework that gives more flexibility on the layout.
Here are two examples that could be solved through this framework:
While these APIs would be purely internal for now, this abstraction work will be very useful in the future to (1) let users customize some parts of the layouts (2) let plugin/apps inject and customize layout.
NOT READY FOR IMPLEMENTATION / JUST FOR DISCUSSION
The text was updated successfully, but these errors were encountered:
In the short term, I think it's not a priority to introduce these behavior exceptions for now (even for People in the Company). This week, I will try to work on a universal design to display object relations on show pages. #2903 I think this would be enough for V1. Don't you think @FelixMalfait?
@Bonapara yes I agree, not a short-term prio for implementation, but I created this issue because I think we should have the vision and a rough plan (how is it going to be implemented, how complex is it, when will it become a priority, etc.). This would allow taking a decision on related issues (e.g. one short term priority is that I have to upload CSV for 2 accounts that asked to, and I cannot do it well with the current CSV upload feature which is too limited, and somehow linked to this issue indirectly)
We recently refactored the codebase to abstract objects and fields, both on the frontend and on the backend.
We now have a standardized way to create a objects, it's much faster to introduce new standard objects and user can even create their own custom objects.
But we lost some flexibility in the way. Because those concepts have been abstracted, it's now harder to have a particular behavior for a particular object. For example we might want to have a middleware for companies on the backend that transforms data upon creation (enrichment). Or on the frontend, we might want to have a specific layout - such as showing the employees on the companies object in a different way than we show other "related objects".
This issue is only about the frontend side, the goal is to create a framework that gives more flexibility on the layout.
Here are two examples that could be solved through this framework:
twenty/packages/twenty-front/src/modules/object-record/components/RecordShowPage.tsx
Line 243 in 5bdca9d
While these APIs would be purely internal for now, this abstraction work will be very useful in the future to (1) let users customize some parts of the layouts (2) let plugin/apps inject and customize layout.
NOT READY FOR IMPLEMENTATION / JUST FOR DISCUSSION
The text was updated successfully, but these errors were encountered: