Handling Auxiliary Tables in Reusable Components
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
x
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.
This is the material presented in the VanJS talks on Oct/18/2023
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!
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.
WHOAMI
First computer I used in college (Basic course): 2Kb
RAM + cassette memory!
Fun facts
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”.
Once we learn whatever stack enough to build what you need, our job
comes to choose:
THIS PRESENTATION
Which approach?
What resources and dependencies?
When to be plain and when to be more sophisticated?
x
This presentation is about the choices made in a personal project where I was
free to experience a lot.
G
oal 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
G
oal 2: To have a boilerplate front-end to easily spin future POCs
experimenting with other tech
THE POC
Just to set up a working prototype with a very basic login and crud
Auxiliary tables start to pop up
•
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
As I have seen and used in past projects, display and validation for a given
“table” info can be:
APPROACH COULD HAVE BEEN
•
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
…
The REST response should contain:
APPROACH WAS
{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
t
hese are text files with a
couple of hundred bytes and we can always cache (several options on how)
CRUD typically has
:
1
ST
CONVENTION
•
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
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?
We just used:
<AuxList />
<AuxItem />
An object like this:
THE FORMAT
{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
No:
{client: “John Doe”,
address: {Street: “Main Street:
…
But:
{cl
ient: “John Doe”,
address_street: “Main Street”
AUTO-IMPOSED LIMITATIONS
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
The fields for these aux tables have one level array or object. Example:
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
BACK-END
name
:
'cod’
I
dentifies which field is being shown and updated by that
Input tag.
NAME ATTRIBUTES
listHeader
:
'Roles'
itemHeader
:
'Role’
label
:
‘Cod’
HEADER AND NAME ATTRIBUTES
‘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:
'select'
Defines which Field tag (in this case through react-bootstrap components)
will be used. Here, we we needed:
TYPE ATTRIBUTE
•
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
b
e 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
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-base
1
to
ctr-client-react-
base
2, the difference being the conversion into TypeScript
https://github.com/plinioprado/ctr-client-react-base
2
https://github.com/plinioprado/ctr-server-node-base1
Plinio Prado
www.linkedin.com/in/plinioprado
www.github.com/plinioprado
www.plinioprado.com
THANKS
Thanks!
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.
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.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
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
THANKS Thanks! Plinio Prado www.linkedin.com/in/plinioprado www.github.com/plinioprado www.plinioprado.com
