tony-shannon
commented
6 years ago this is a few related notes from @simongamester
PulseTile-React Setup Notes
Clone / Download from Github Then…
Just installed locally on my mac and running under localhost. Get the following error when accessing a patient dashboard: "Error 400: synopsis has not yet been added to middle-tier processing" It is because some requests can't work locally until we change them. What should you do, if you want to run this project locally:
1) Add requests from attached file to paths, which are written above each request code; 2) Login to http://dev.ripple.foundation:8000/ 3) Copy token from http://dev.ripple.foundation:8000/api/patients/9999999000/synopsis/top3Things to the path: /src/config/for-test.constants.js 4) Restart NPM File below…
-- LOGIN AND PASSWORD
ivor.cox@ripple.foundation IvorCox1!
-- DEMOGRAPHICS /src/ducks/fetch-patient-demographics.duck.js
export constfetchPatientDemographicsEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_DEMOGRAPHICS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/demographics/${payload.userId}, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientDemographicsSuccess({
userId: payload.userId,
demographics: get(response, 'demographics', {}),
}))
);
-- SYNOPSIS
/src/components/pages/Allergies/ducks/fetch-patient-allergies.duck.js:
export constfetchPatientAllergiesSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_ALLERGIES_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/allergies, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientAllergiesSuccess({
userId: payload.userId,
allergies: get(response, 'synopsis', []),
}))
);
/src/components/pages/Contacts/ducks/fetch-patient-contacts.duck.js
export constfetchPatientContactsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_CONTACTS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/contacts, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientContactsSuccess({
userId: payload.userId,
contacts: get(response, 'synopsis', []),
}))
);
/src/components/pages/Diagnosis/ducks/fetch-patient-diagnoses.duck.js
export constfetchPatientDiagnosesSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_DIAGNOSES_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/problems, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientDiagnosesSuccess({
userId: payload.userId,
diagnoses: get(response, 'synopsis', []),
}))
);
/src/components/pages/Medications/ducks/fetch-patient-medications.duck.js
export constfetchPatientMedicationsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_MEDICATIONS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/medications, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientMedicationsSuccess({
userId: payload.userId,
medications: get(response, 'synopsis', []),
}))
);
/src/components/pages/TopThreeThings/ducks/fetch-patient-top-three-things.duck.js
export constfetchPatientTopThreeThingsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_TOP_THREE_THINGS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/top3Things, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientTopThreeThingsSuccess({
userId: payload.userId,
topThreeThings: get(response, 'synopsis', []),
}))
);
/src/components/pages/Vaccinations/ducks/fetch-patient-vaccinations.duck.js
export constfetchPatientVaccinationsSynopsisEpic = (action$, store) =>
action$.ofType(FETCH_PATIENT_VACCINATIONS_SYNOPSIS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/patients/${payload.userId}/synopsis/vaccinations, {
Authorization: 'Bearer '+testConstants.token
})
.map(response =>fetchPatientVaccinationsSuccess({
userId: payload.userId,
vaccinations: get(response, 'synopsis', []),
}))
);
-- FEEDS
/src/components/pages/Feeds/ducks/fetch-feeds.duck.js
export constfetchFeedsEpic = (action$, store) =>
action$.ofType(FETCH_FEEDS_REQUEST)
.mergeMap(({ payload }) =>
ajax.getJSON(http://dev.ripple.foundation:8000/api/feeds, {
Authorization: 'Bearer '+testConstants.token
})
.map((response) => {
return fetchFeedsSuccess({ feeds: response })
})
);
pacharanero
simongamester
Need refresh of set up documentation
Some recent threads of note
///// [10:32:50] Simon @ Root Solutions: Thanks, I've forked this and will make changes here. [10:39:23] Simon @ Root Solutions: Just installed locally on my mac and running under localhost. Get the following error when accessing a patient dashboard: "Error 400: synopsis has not yet been added to middle-tier processing" [10:40:46] Simon @ Root Solutions: Does the ripple middleware need to be installed locally? [10:55:36 | Edited 10:57:30] Bogdan Shcherban: [10:39] Simon @ Root Solutions:
<<< Just installed locally on my mac and running under localhost. Get the following error when accessing a patient dashboard: "Error 400: synopsis has not yet been added to middle-tier processing"It is because some requests can't work locally until we change them. What should you do, if you want to run this project locally:
1) Add requests from attached file to paths, which are written above each request code; 2) Login to http://dev.ripple.foundation:8000/ 3) Copy token from http://dev.ripple.foundation:8000/api/patients/9999999000/synopsis/top3Things to the path: /src/config/for-test.constants.js 4) Restart NPM [11:57:41] Simon @ Root Solutions: Thanks Bogdan, this works! [11:58:14] Bogdan Shcherban: You're welcome! [11:58:53] Simon @ Root Solutions: Are there plans to get it running in dev without the need to make code changes? [12:01:08] Bogdan Shcherban: It is necessary to ask Rob about it. Because it isn't conveniently - change the code each time when we want to make some changes in the code. [12:02:08] Rob Tweed: What's the question? [12:05:11] Bogdan Shcherban: Each time when we want to run the project locally - we should change requests for Demographics and Headings (Allergies, Contacts etc.). And it is usually possible to forgot about this changes before commiting. [12:06:52] Rob Tweed: When you say "run locally" what do you mean? The APIs expected by the QEWD Middle tier are the APIs expected to be sent by PulseTile. If you're replacing the middle tier with something else locally, then that alternative back-end should emulate the same APIs. PulseTile shouldn't have to be changed [12:08:07] Rob Tweed: SO there's nothing I can do about it - the QEWD / Helm / Ripple APIs are the APIs that you should be working against - end of [12:08:54] Simon @ Root Solutions: Hi Rob, so is the best approach when working on PulseTile on localhost to also run the middle tier locally? [12:09:16] Rob Tweed: WHat are you running it against locally otherwise? I don't understand [12:09:43] Rob Tweed: I don't understand what you mean by "running locally" [12:10:31] Simon @ Root Solutions: I'm just running npm start of PulseTile-React on my mac. [12:10:45] Simon @ Root Solutions: viewing pulsetile on localhost:3000 [12:10:55] Rob Tweed: PulseTile should be designed to work against the APIs provided by the Helm / QEWD Middle tier. Either you run PulseTile against an instance of the actual QEWD Middle tier, or you run it against something that emulates the exact same APIs and emuates their behaviour. [12:11:29] Simon @ Root Solutions: For the purposes of UI development, the data can just be emulated I think. [12:11:33] Rob Tweed: Otherwise how can it be expected to work? I don't understand what you're attempting to do [12:12:06] Rob Tweed: Well if you're emulating the back-end, then you need your emulation to behave exactly the same as the actual back end that PulseTile is designed to expect [12:13:38] Rob Tweed: ALternatively you did see my instructions on how to set up a local instance of the QEWD platform, right? It's just a set of Docker Containers that you fire up according to my instructions, and you have a local platform you can use for development [12:15:21] Simon @ Root Solutions: Was that on a Skype? Not sure I have that to hand. Can you resend please? Rob Tweed [12:23:09] Simon @ Root Solutions: Thanks Rob. So once this is up and running, should PulseTile run on localhost or the Ubuntu VM? [12:24:36] Rob Tweed: The PulseTile UI files are served up by the conductor-service-phr container. The repo already contains a copy of the files, but you'd just replace them with your latest version [12:24:53] Rob Tweed: See https://github.com/RippleOSI/Ripple-QEWD-Microservices/tree/master/conductor-service-phr/www [12:35:01] Simon @ Root Solutions: So would we just drop the PulseTile-React/src folder in here? These files look different. https://github.com/LeedsCC/PulseTile-React/tree/master/src [12:35:56] Rob Tweed: What you drop in there are the built files, not the source files - they need to be the versions that actually run in a browser [12:36:28] Rob Tweed: but yes - all you do is drop the built files into that folder [12:37:23] Simon @ Root Solutions: So presumably we'd need to update the npm scripts which build from src so they build to this location instead? [12:37:48] Rob Tweed: You need to decide how that would have to work [12:41:00] Simon @ Root Solutions: OK, sound like this might need a bit more thought. Maybe a quick alternative would be to run the midldeware on a cloud server then reference it in the PulseTile config and run that locally? [12:42:37] Rob Tweed: Whatever happens, we need a set of pre-built files that can be dropped into an instance of that conductor-service-phr container's folder [12:43:53] Rob Tweed: Anyone running the Helm PHR will be running the microservices as described in that document, and your PulseTile UI files will be served up from this container [12:44:45] Rob Tweed: I suggest you set up an instance by following the instructions in that document so you can see for yourselves how it all works for real, and you can then figure out what you need to do [13:00:02] Simon @ Root Solutions: Thanks Rob. Bogdan, what would you suggest as the best way forward? [13:09:30] Bogdan Shcherban: In Core project we have two places for build location: folder '/dist' - for the last build folder '/build' - for builds storage
But in LeedsCC we can see only the second. But we can take any of these zip-archives and unpack them [13:09:54] Bogdan Shcherban: Later I will see, why dist folder is absent here. It must be [13:17:55] Simon @ Root Solutions: Yes, /dist isnt' being generated on my copy either, although I can see it's defined in webpack.config.dev. Assuming we set up the server suggested by Rob, shouldn't we just update const buildPath = path.join(__dirname, 'dist'); to the www share path on the VM?
/// what lessons can we learn from this