A react.js frontend panel

___________________________________________________________ overview ## goal - provide UI and convenient experience to users. ## terminology - user People that will log in and use our system. - account Each user have a list of accounts (say 10~150). Account is used to login third-party system. An account has three things: account, password, remark - order User can place orders (1~50) to specific date. Each order has 1. a date 2. a boolean concession 3. a remark 4. a list of jobs (>1) - job is an copy of one account with two more fields profile and remark - result each job should have may have 0 or more than one result each result has 1. status : String 2. hkid (optional) ... (more to come, not finalized yet) - email each email at most correspond to 1 result each email contain 1. TranNo 2. TranDate 3. TranTime 4. TranRef 5. TranTotal 6. HKID 7. playDate 8. playDay 9. facility 10. venue 11. {timeStart, timeEnd, courtNo, courtPrice} x 4 - template a date-independent set of order so that it can be apply to any date. ## description ___________________________________________________________ task ## task - login page - admin panel - create/list/patch/delete/hard_delete user - change username/password/nickname - list all client orders by date in one page - list all result by date in one page - confirmation of result_email - client panel - change login password - add/patch/delete account - add/patch/delete order by date - add/patch/delete job to order - save/load specific day of orders to be template - result_email in one page ___________________________________________________________ schedule ## definition (to be confirmed) ___________________________________________________________ development ## definition - you should git your source code. - you can upload your files via sftp acc: (provide later) pwd: (provide later) just upload to /public/* and the it will map to /s/* ___________________________________________________________ database schema ## definition - database schema should be somehow stable except the templat part. - first version of test data is done, but expect the database maybe rebuild from time to time. i.e. Data you entered, maybe removed or data you removed maybe retrieved. This is normal. - FYI, all user are with password 'test', there are user 'admin', 'user1', 'user2', 'user3' ... - see the database schema and data from [login to view URL] acc: alfred pwd: Eh7CyFfuzVZNmG9F - feel free to modify the test data, they are test data. ___________________________________________________________ technology ## definition - you can use whatever library/framework providing that 1. it should work in common browsers (i.e. chrome, ie11, andriod, ios) 2. do not depend on third-party plugins (i.e. Java, flash) generally speaking, the final source code should be pure html5 + css + js(es5) - one limitation is that files must be static. This allows scalable file serving and separation of development. (i.e. no server-side generated files) - all fontendb backend communication are via ajax (see api) - the technology you use should provide reasonable performance - it is highly appreciated if it is responsible (we assume users are novice and will visit on mobile/tablet/desktop.) ___________________________________________________________ api ## definition - it is proposed to not follow restful api - ask if you think something is missing or block your work or make your work difficult. - Request to /api/* always respond in json - all api allow CORS for your convenience of development, but they will turn off when production. - We use [Boom]([login to view URL]) for error generation => if the respond is error, there are always three keys: statusCode, error, message, it is safe that check whether respond object has error field to determine whether it is an error response. i.e. if( [login to view URL] ) { // this is error response } else { // this is normal response } - this is the hostname for development [login to view URL] - a list of api can be found on [login to view URL] - not all api have description, and it will never be. The api is expected to be intuitive enough, ask if you find it doesn't make sense to you. - routes with 'stable', 'locked' tag should be considered that the interface will not change. For those that without, I will try to mark them stable as soon as possible. ___________________________________________________________ miscellaneous ## precaution - the login page must be named [login to view URL] and in the root folder. - all other files will be mount on /s/* - Due to the separation of development, you probably would need to hard code the hostname of server ([login to view URL]), but you should make it easy to change. [login to view URL] is not the production server ___________________________________________________________