Handling Auxiliary Tables in Reusable Components

Slide Note

Approach for managing auxiliary tables efficiently within main features using a data format response. Presentation details Plinio Prado's exploration of different alternatives and his experience in transitioning front-end to TypeScript after the project. The talk emphasizes making informed choices on resources and dependencies when building personal projects with the freedom to experiment.

cash Follow

Uploaded on Apr 04, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript

ONE APPROACH FOR REUSABLE COMPONENTS USING A DATA + FORMAT RESPONSE Helping to handle the swarm of auxiliary tables that fly around your main features Plinio Prado October 2023

POST PRESENTATION EDIT This is the material presented in the VanJS talks on Oct/18/2023 It s not about a new technology or service or something revolutionary, but the most successful approach for a problem when I had time to research and play with several alternatives (not always something we can afford) to handle that swarm of aux tables that often start popping up in our projects. x As noted in one of the next slides, after the presentation the project s front end was moved to a version 2 in a new repo, the difference being the implementation of TypeScript. Have fun!

WHOAMI PLINIO PRADO A software developer who has worked in lots of different Business and Financial applications, and also a former Finance professional who used and procured them.

Fun facts First computer I used in college (Basic course): 2Kb RAM + cassette memory! First computer I was paid to code on (inventory control when intern): 64Kb RAM plus a pair of 360Kb disks!! One for the the language and one for your app. That s why I m very annoying in my cost/benefit analysis when adding dependencies (like moment.js and its 14.3 Mb on disk). As my great grandfather Plinio (the elder) used to say: The engineer is the guy who does with 1 what any idiot does with 2 .

THIS PRESENTATION Once we learn whatever stack enough to build what you need, our job comes to choose: Which approach? What resources and dependencies? When to be plain and when to be more sophisticated? This presentation is about the choices made in a personal project where I was free to experience a lot. x

THE POC Goal 1: Recap JavaScript/React and what evolved over the last 5 years when I worked on a now-delivered project using in the back-end a language I don t want to see again Goal 2: To have a boilerplate front-end to easily spin future POCs experimenting with other tech

Auxiliary tables start to pop up Just to set up a working prototype with a very basic login and crud Settings Users Roles Tenants And for this prototype, for starters: Countries: Base ISO 3166 Currencies: Base ISO 4217 Then type of this validation of that not all deserving a table but all deserving a basic crud or at least display for the admin user

APPROACH COULD HAVE BEEN As I have seen and used in past projects, display and validation for a given table info can be: Code one component per table and reuse whatever we can Generic component with param or code stored somewhere in in front-end Embed in the response Load in their own requests when we know will use that one

APPROACH WAS The REST response should contain: { data: can be either Item (object) or a list (array of item objects) format: rendering, validation and Business logic } Yes. Loading on each request has a cost, but these are text files with a couple of hundred bytes and we can always cache (several options on how)

1STCONVENTION CRUD typically has : A List with some items to browse over the records (with some filters, etc.) An Item with the full info of a selected record can be seen and an update We just used: <AuxList /> <AuxItem /> Here, the threshold for when to use these Aux components or custom- coded was: - Does it use special components in the Item (Like something collapsible)? - Does it have business rules involving multiple fields?

THE FORMAT An object like this: { listHeader: 'Roles , itemHeader: 'Role', columns: [ { name: 'cod', listPosition: 1, formPosition: 1, type: 'string', primaryKey: true, default: '', required: true, label: 'Cod', fieldMd: 6, minlength: 3, maxlength: 6 }, ... ] }

MOONGOSE-LIKE ALTERNATE FORMAT { 'header' : { listHeader: 'Roles', itemHeader: 'Role' }, 'cod' : { listPosition: 1, formPosition: 1, type: 'string', primaryKey: true, default: '', required: true, label: 'Cod', fieldMd: 6, minlength: 3, maxlength: 6 }, ... ] } Loops differently but works in the end is quite similar. Might change to this just because the known and documented Mongoose has a lot of useful validation attributes

AUTO-IMPOSED LIMITATIONS The fields for these aux tables have one level array or object. Example: No: But: { { client: John Doe , address: { Street: Main Street: client: John Doe , address_street: Main Street JavaScript loops can perfectly crawl recurrently to handle objects within objects I used it in some core components, works but adds a complexity that shouldn't be needed in an Aux table

BACK-END Irrelevant for the C of this POC This concept being explored is about the format of the REST responses and the rendering of the React front-end The code happens to use the format as a schema to run back-end validation and build SQL queries, nice but beside the point

NAME ATTRIBUTES name: 'cod Identifies which field is being shown and updated by that Input tag.

HEADER AND NAME ATTRIBUTES listHeader: 'Roles' itemHeader: 'Role label: Cod label defines AuxList column header and AuxItem field label but they could be different, as here we can add any text to be shown

TYPE ATTRIBUTE type: 'select' Defines which Field tag (in this case through react-bootstrap components) will be used. Here, we we needed: boolean (select between true and false) integer password select (the only one that will use the 'options' attribute) serial (numeric serial) text (the default) Not used the Mongoose types they are just the type of the variable and here also define the HTML tag, and additional business rules

LAYOUT ATTRIBUTES listPosition: 1 Order in the AuxList columns, zero means don t render formPosition: 1 Order in the AuxItem components, within a Bootstrap/Flexbox grid fieldMD: 6 1/12 width for the Bootstrap/Flexbox grid rendering. May need also a fieldSm and fieldLg, just but so far wasn't been needed Using Bootstrap naming conventions

TAG ATTRIBUTES primaryKey: true default: '' required: true minlength: 3 maxlength: 6 Naming followed HTML tags (naming is a b*tch) Drives also the front-end validation that runs in AuxList so the Submit button can be conditionally disabled. Validating in the Field tag was tempting but please only in one place

OPTIONS FOR THE SELECT TAGS options: [ { value: 'default', text: 'default' } ] Either hardcoded in the schema source, or computed when the request happens

CODE https://github.com/plinioprado/ctr-client-react-base2 https://github.com/plinioprado/ctr-server-node-base1 Notes: Most applications use Float with 2 digits for currency but that is most but not all I question the choice of using as the Country primary key the 3 char code (it s the most commonly mentioned), could have used the 2 char code It s a POC so time was focused in some places and not in others (filtering really deserves better) POST PRESENTATION EDIT: Since the meetup, the front end of this project moved from ctr-client-react-base1 to ctr-client-react- base2, the difference being the conversion into TypeScript