front-end-monorepo
front-end-monorepo copied to clipboard
Panoptes JS: add lib-panoptes-js dev server, add experimental auth
PR Overview
Package: lib-panoptes-js Part of: replacing PJC with Panoptes JS
This PR is part of an experiment to remove PJC from FEM, replacing its functionality fully with making Panoptes JS (PanoptesJS? panoptes.js?)
This PR focuses on some small steps:
- an experimental-auth.js file has been added to lib-panoptes-js
- The plan: we'll copy PJC's
auth
, one bit of functionality at a time, into PanoptesJS'sexperimentalAuth
. We'll eventually turn experimentalAuth into auth once we're confident all the features are working. - Features in this PR:
- ✔️ event listener system is functional (addEventListener(), removeEventListener(), broadcastEvent() ; these are analogous to PJC's listen(), stopListening(), and emit())
- 🛠️ basic sign in action is a WIP (goal: signIn() should, if given a valid username & password, return a Panoptes User resource. That's it.)
- The plan: we'll copy PJC's
- a dev server has been added to lib-panoptes-js
- Run with
yarn dev
- Dev server serves a very basic form to test login.
- Run with
Dev Notes
- As noted on Slack discussions, I have issues with how Panoptes JS is supposed to (based on the documentation) be "stateless", which conflicts incredibly with how PJC's auth functionality handles login state. (My argument is that if we're moving login state handling to modules/packages that call Panoptes JS, then we're just basically moving the burden up to the modules/packages.)
- Nonetheless, I'm trying a hybrid to see if I can stay (semi-)true to the Panoptes JS goals:
- experimentalAuth exports functions, not a single instantiated object. (cf PJC's auth object)
- each function in experimentalAuth has an optional
store
variable that can be specified by the calling module/function. - if a store isn't specified (which I imagine is the case 99% of the time), the functions use a default, shared, global store.
Status
Experimental WIP.