Should I use Javascript Classes or Apex Classes in Lightning Web Components? [on hold]
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I am working on designing a timesheet Lightning Web Component for my company. Internally, we use a sObject that tracks individual sessions, which then gets rolled up one way to generate payroll, and another way to create invoices. To that end, we don't have a timesheet sObject in our schema (we do have a paystub sObject, but we run payroll every two weeks and collect timesheets every week).
The general flow of what needs to happen is run a SOQL query, transform the data into rows (clients) and columns (dates), and then display the data for viewing and editing. The SOQL clearly happens in an Apex class, and the display is clearly happening in an LWC, but I am unclear about the transformation stage. Would it make sense to have an Apex class gather all the data, transform it, and then @wire the data to the LWC row by row? Or should I just use the Apex class to generate all of the data, @wire a list to the LWC, and use Javascript objects to sort everything into rows and columns?
apex soql lightning-web-components
New contributor
put on hold as primarily opinion-based by Jayant Das, Sebastian Kessel, Reshma, Pranay Jaiswal, Raul 2 days ago
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I am working on designing a timesheet Lightning Web Component for my company. Internally, we use a sObject that tracks individual sessions, which then gets rolled up one way to generate payroll, and another way to create invoices. To that end, we don't have a timesheet sObject in our schema (we do have a paystub sObject, but we run payroll every two weeks and collect timesheets every week).
The general flow of what needs to happen is run a SOQL query, transform the data into rows (clients) and columns (dates), and then display the data for viewing and editing. The SOQL clearly happens in an Apex class, and the display is clearly happening in an LWC, but I am unclear about the transformation stage. Would it make sense to have an Apex class gather all the data, transform it, and then @wire the data to the LWC row by row? Or should I just use the Apex class to generate all of the data, @wire a list to the LWC, and use Javascript objects to sort everything into rows and columns?
apex soql lightning-web-components
New contributor
put on hold as primarily opinion-based by Jayant Das, Sebastian Kessel, Reshma, Pranay Jaiswal, Raul 2 days ago
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
If I had to design this, I would have created a wrapper class to collect all data within the Apex and then return theList<MyWrapperClass>
to the LWC. This way I would keep all the logic of fetching/transforming/saving data consolidated at one place.
– Jayant Das
Apr 15 at 18:06
add a comment |
I am working on designing a timesheet Lightning Web Component for my company. Internally, we use a sObject that tracks individual sessions, which then gets rolled up one way to generate payroll, and another way to create invoices. To that end, we don't have a timesheet sObject in our schema (we do have a paystub sObject, but we run payroll every two weeks and collect timesheets every week).
The general flow of what needs to happen is run a SOQL query, transform the data into rows (clients) and columns (dates), and then display the data for viewing and editing. The SOQL clearly happens in an Apex class, and the display is clearly happening in an LWC, but I am unclear about the transformation stage. Would it make sense to have an Apex class gather all the data, transform it, and then @wire the data to the LWC row by row? Or should I just use the Apex class to generate all of the data, @wire a list to the LWC, and use Javascript objects to sort everything into rows and columns?
apex soql lightning-web-components
New contributor
I am working on designing a timesheet Lightning Web Component for my company. Internally, we use a sObject that tracks individual sessions, which then gets rolled up one way to generate payroll, and another way to create invoices. To that end, we don't have a timesheet sObject in our schema (we do have a paystub sObject, but we run payroll every two weeks and collect timesheets every week).
The general flow of what needs to happen is run a SOQL query, transform the data into rows (clients) and columns (dates), and then display the data for viewing and editing. The SOQL clearly happens in an Apex class, and the display is clearly happening in an LWC, but I am unclear about the transformation stage. Would it make sense to have an Apex class gather all the data, transform it, and then @wire the data to the LWC row by row? Or should I just use the Apex class to generate all of the data, @wire a list to the LWC, and use Javascript objects to sort everything into rows and columns?
apex soql lightning-web-components
apex soql lightning-web-components
New contributor
New contributor
New contributor
asked Apr 15 at 18:00
Andrew FavaloroAndrew Favaloro
333
333
New contributor
New contributor
put on hold as primarily opinion-based by Jayant Das, Sebastian Kessel, Reshma, Pranay Jaiswal, Raul 2 days ago
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as primarily opinion-based by Jayant Das, Sebastian Kessel, Reshma, Pranay Jaiswal, Raul 2 days ago
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
If I had to design this, I would have created a wrapper class to collect all data within the Apex and then return theList<MyWrapperClass>
to the LWC. This way I would keep all the logic of fetching/transforming/saving data consolidated at one place.
– Jayant Das
Apr 15 at 18:06
add a comment |
1
If I had to design this, I would have created a wrapper class to collect all data within the Apex and then return theList<MyWrapperClass>
to the LWC. This way I would keep all the logic of fetching/transforming/saving data consolidated at one place.
– Jayant Das
Apr 15 at 18:06
1
1
If I had to design this, I would have created a wrapper class to collect all data within the Apex and then return the
List<MyWrapperClass>
to the LWC. This way I would keep all the logic of fetching/transforming/saving data consolidated at one place.– Jayant Das
Apr 15 at 18:06
If I had to design this, I would have created a wrapper class to collect all data within the Apex and then return the
List<MyWrapperClass>
to the LWC. This way I would keep all the logic of fetching/transforming/saving data consolidated at one place.– Jayant Das
Apr 15 at 18:06
add a comment |
1 Answer
1
active
oldest
votes
Unless the transformation significantly reduces the amount of data you have to send from the server to the client, it most likely makes sense to do as much as possible in the client (JavaScript). JavaScript is far more efficient in CPU time than Apex, so you'll reduce the overall time the user has to wait for the results to appear. Also, if you decide you later want to provide different options (filtering, sorting, etc), you can avoid network activity entirely by using JavaScript as much as possible, allowing near-instant updates to the page.
1
Adding color to this discussion: ES6.map()
,.filter()
and.reduce()
significantly improve UX at the expense of server-side reusability. You can still offload any helpers to a LWC utils file and find client-side reusability there.
– tsalb
Apr 15 at 20:22
I know that the LWC framework is built on top of ES5, how much of ES6 is available/unavailable?
– Andrew Favaloro
Apr 16 at 14:08
@AndrewFavaloro this doc goes in to detail, but essentially, all of ES6 and ES7, most of ES8, and some of ES9.
– sfdcfox
Apr 16 at 14:24
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Unless the transformation significantly reduces the amount of data you have to send from the server to the client, it most likely makes sense to do as much as possible in the client (JavaScript). JavaScript is far more efficient in CPU time than Apex, so you'll reduce the overall time the user has to wait for the results to appear. Also, if you decide you later want to provide different options (filtering, sorting, etc), you can avoid network activity entirely by using JavaScript as much as possible, allowing near-instant updates to the page.
1
Adding color to this discussion: ES6.map()
,.filter()
and.reduce()
significantly improve UX at the expense of server-side reusability. You can still offload any helpers to a LWC utils file and find client-side reusability there.
– tsalb
Apr 15 at 20:22
I know that the LWC framework is built on top of ES5, how much of ES6 is available/unavailable?
– Andrew Favaloro
Apr 16 at 14:08
@AndrewFavaloro this doc goes in to detail, but essentially, all of ES6 and ES7, most of ES8, and some of ES9.
– sfdcfox
Apr 16 at 14:24
add a comment |
Unless the transformation significantly reduces the amount of data you have to send from the server to the client, it most likely makes sense to do as much as possible in the client (JavaScript). JavaScript is far more efficient in CPU time than Apex, so you'll reduce the overall time the user has to wait for the results to appear. Also, if you decide you later want to provide different options (filtering, sorting, etc), you can avoid network activity entirely by using JavaScript as much as possible, allowing near-instant updates to the page.
1
Adding color to this discussion: ES6.map()
,.filter()
and.reduce()
significantly improve UX at the expense of server-side reusability. You can still offload any helpers to a LWC utils file and find client-side reusability there.
– tsalb
Apr 15 at 20:22
I know that the LWC framework is built on top of ES5, how much of ES6 is available/unavailable?
– Andrew Favaloro
Apr 16 at 14:08
@AndrewFavaloro this doc goes in to detail, but essentially, all of ES6 and ES7, most of ES8, and some of ES9.
– sfdcfox
Apr 16 at 14:24
add a comment |
Unless the transformation significantly reduces the amount of data you have to send from the server to the client, it most likely makes sense to do as much as possible in the client (JavaScript). JavaScript is far more efficient in CPU time than Apex, so you'll reduce the overall time the user has to wait for the results to appear. Also, if you decide you later want to provide different options (filtering, sorting, etc), you can avoid network activity entirely by using JavaScript as much as possible, allowing near-instant updates to the page.
Unless the transformation significantly reduces the amount of data you have to send from the server to the client, it most likely makes sense to do as much as possible in the client (JavaScript). JavaScript is far more efficient in CPU time than Apex, so you'll reduce the overall time the user has to wait for the results to appear. Also, if you decide you later want to provide different options (filtering, sorting, etc), you can avoid network activity entirely by using JavaScript as much as possible, allowing near-instant updates to the page.
answered Apr 15 at 18:14
sfdcfoxsfdcfox
266k13212459
266k13212459
1
Adding color to this discussion: ES6.map()
,.filter()
and.reduce()
significantly improve UX at the expense of server-side reusability. You can still offload any helpers to a LWC utils file and find client-side reusability there.
– tsalb
Apr 15 at 20:22
I know that the LWC framework is built on top of ES5, how much of ES6 is available/unavailable?
– Andrew Favaloro
Apr 16 at 14:08
@AndrewFavaloro this doc goes in to detail, but essentially, all of ES6 and ES7, most of ES8, and some of ES9.
– sfdcfox
Apr 16 at 14:24
add a comment |
1
Adding color to this discussion: ES6.map()
,.filter()
and.reduce()
significantly improve UX at the expense of server-side reusability. You can still offload any helpers to a LWC utils file and find client-side reusability there.
– tsalb
Apr 15 at 20:22
I know that the LWC framework is built on top of ES5, how much of ES6 is available/unavailable?
– Andrew Favaloro
Apr 16 at 14:08
@AndrewFavaloro this doc goes in to detail, but essentially, all of ES6 and ES7, most of ES8, and some of ES9.
– sfdcfox
Apr 16 at 14:24
1
1
Adding color to this discussion: ES6
.map()
, .filter()
and .reduce()
significantly improve UX at the expense of server-side reusability. You can still offload any helpers to a LWC utils file and find client-side reusability there.– tsalb
Apr 15 at 20:22
Adding color to this discussion: ES6
.map()
, .filter()
and .reduce()
significantly improve UX at the expense of server-side reusability. You can still offload any helpers to a LWC utils file and find client-side reusability there.– tsalb
Apr 15 at 20:22
I know that the LWC framework is built on top of ES5, how much of ES6 is available/unavailable?
– Andrew Favaloro
Apr 16 at 14:08
I know that the LWC framework is built on top of ES5, how much of ES6 is available/unavailable?
– Andrew Favaloro
Apr 16 at 14:08
@AndrewFavaloro this doc goes in to detail, but essentially, all of ES6 and ES7, most of ES8, and some of ES9.
– sfdcfox
Apr 16 at 14:24
@AndrewFavaloro this doc goes in to detail, but essentially, all of ES6 and ES7, most of ES8, and some of ES9.
– sfdcfox
Apr 16 at 14:24
add a comment |
1
If I had to design this, I would have created a wrapper class to collect all data within the Apex and then return the
List<MyWrapperClass>
to the LWC. This way I would keep all the logic of fetching/transforming/saving data consolidated at one place.– Jayant Das
Apr 15 at 18:06