Open xidus opened 3 years ago
Jeg synes bestemt det giver mening.
En udfordring med at flytte kode fra fire.cli-laget til et dybere API-lag er blandt andet, at der i den nuværende regnearksfunktionalitet bliver skrevet til brugerens terminal med fire.cli.print. CLI-modulets funktionalitet er det yderste lag af applikationen og bør derfor ikke være en afhængighed for dybere-liggende moduler.
Kan vi løse den her med indføring af en logger? Så de forskellige funktioner i stedet for at bruge fire.cli.print()
smider deres information i en log, som CLI'en efterfølgende kan vælge at skrive på skærmen til brugeren.
Logning vill være en god løsning generelt. Med hensyn til eksisterende tilbagemeldinger til brugeren, så skal der måske smides nogle exceptions, som kan håndteres længere oppe, i.e. i fire-kommandoerne.
God ide med exceptions. Jeg har flere gange tænkt det kunne være nyttigt med en global exception handler. Jeg ved ikke hvor nemt det er at implementere, men det kunne gøre koden ret lækker. Fx, ved fejl smides en exception (inklusiv fejlbeskrivelse brugeren kan forstå), der gribes af den globale handler som så skriver fejlen pænt på skærmen og dumper stack trace osv i en log-fil. Så kan brugeren vedhæfte loggen i tilfælde af det er en fejl der skal håndteres i et issue.
Regnearksfunktionaliteten i fire.cli.niv har bør ligge i et separat modul med dette tema. Det er forsøgt startet i #475 med et fire.io.regneark-modul, og her er tilføjet en række nye funktioner i forbindelse med dette PR.
En udfordring med at flytte kode fra fire.cli-laget til et dybere API-lag er blandt andet, at der i den nuværende regnearksfunktionalitet bliver skrevet til brugerens terminal med fire.cli.print. CLI-modulets funktionalitet er det yderste lag af applikationen og bør derfor ikke være en afhængighed for dybere-liggende moduler.
En ekstra udfordring er derfor, at brugerens nuværende oplevelse med de eksisterende tilbagemeldinger fra programmet i terminalen skal afkobles fra funktionaliteten, som ikke bør vide noget om, hvordan den bliver anvendt; samtidig skal brugeren ikke miste væsentlige tilbagemeldinger fra programmet.
Med accept af #475 vil der desuden være kode med overlappende funktionalitet, så det vil være nødvendigt at få skrevet de to modulers funktionalitet sammen eller skifte det ene ud med det andet.
Ændringerne forudsætter, at vi har en samlet plan for tilsvarende refaktoriseringer af hele kodebasen.