Summary
I have an app which monitors a characteristic of a BLE device. It has to react to the changes (BLE device notifies of changes), save them, calculate some stuff and then display a plot, some values and a gps map. The data changes with a frequency of about 10Hz.
My current idea of the structure
main screen/component: Starts monitoring the device. On data change, saves raw data, calculates values (calls a function from a native component for performance reasons), sends some data to the plot page, gps page, another page. Returns/renders the following pages.
plot page: Uses expo-gl and threejs to display a plot, plot can be changed by changing values and calling some functions, does not need a state update. Also needs to display 15 values, from my experience fast props updates resulted in extremely poor performance, so I used textInputs with refs before to change them without props/state updates, but that was without gps and then characteristic monitoring was in this component.
gps page: Displays a map with a line which changes with BLE updates. Haven't implemented yet, I'm thinking about using rnmapbox. I'm worried that this requires data as props and therefore might have performance problems. Any ideas here are welcome.
another page: This has to display a table with 30 values. Again as they're fast changing I think refs have to be used. I used refs with 12 values, but I think it's slowly getting out of hand with that many refs.
Main questions I have
How does this structure seem? If anyone has any other ideas, all are welcome.
Is there any other, better way of updating fast-changing values, other that using refs and textInput?
How to structure refs? As there are so many refs, I'm wondering what's the best way of storing and sharing them between the components?
As right now it seems that everything is becoming so coupled, I'm wondering if it would be even better to just put everything in one file? Then the file would be long, but it might allow to omit some confusing parts of sharing data between components.
Thanks to everyone willing to help. It's my first question on here, so any tips on how to structure the question better are welcome.
EDIT:
I think I finally understood accessing child functions from parent component with refs. So I can use that to update most of the stuff without using props and keeping textInput refs in the components they belong to. However I'm still open to any ideas.
Related
Currently working on React-Native where I create numerous screens, I just want to know that how can I optimize the code. Please suggest some tips. Like Number of Screens matter , how to reduce the complexity at abstract level etc.
Please take a good look at using things like useMemo for large computations that don't need to recalculate on rerenders.
https://reactjs.org/docs/hooks-reference.html#usememo
Make sure you extract components properly so when on state change of a small prop not a big component needs to rerender just for one small prop.
Things like this make a big difference.
Vuex is great and too much greatness is not always good.
So how much Vuex is too much Vuex? And how much prop drilling is too much prop drilling?
Let's imagine the following module about editing a contact. How would you share data between your components? Would you rather use Vuex or props with multi-level event emitting?
Please, consider this an abstract example, don't suggest changing the structure of the module:
ContactEdit GETs the data from the server.
ContactEditAvatar shows non-editable part of the data (e.g. the
avatar of the contact)
ContactEditForm shows the editable data and allows the user to edit
it.
ContactEditSubmit contains the submit button, that POSTs the newly
edited data.
How would you pass data around?
There are four options to approach this:
Provider/inject is not considered an option, as it is not recommended for two-way data binding.
We can also eliminate option 3 immediately as it doesn't expose the edited data from ContactEditForm to the submit button in ContactEditSubmit.
But what about 1,2 and 4?
Option 4 keeps all components small, logic is placed next to corresponding template and everything is beautifully modularized.
However, this approach can potentially make tracking data changes a struggle, after the app becomes bigger, so option 2 is a great alternative, because all the module logic is in a single component and anything can be traced easily.
Props and events should also be able to do the job (option 1) and on first sight it actually looks easier and more intuitive.
However, I feel this approach is not scalable enough and can cause real headaches when unexpected changes on the components come in the future. Also, too much props make the code harder to read, imo.
Personally, I would go with option 4, but what do you, guys, think?
Please, when posting your response, share your experience with large-scale SPAs.
Thanks and have a great and productive week ahead
It's more of a software design question, than strictly programming, so I'll paste UML diagrams instead of code for everyone's convenience.
Language is Java, so variables are implied references.
I'm writing an app, that helps edit a very simple data structure, that looks like this:
On my first trial run I've included all the drawing-related and optimization code into the data structure, that is, every Node knew how to draw itself and kept a reference to one of shared cached bitmaps. UML:
It was easy to add (fetch a corresponding bitmap and you're done) and remove (paint background color over previously mentioned bitmap). Performance-wise it was nice, but code-wise it was messy.
So on the next iteration I decided to split things, but I may have went to far and things got messy yet again:
Here data structure and its logic is completely separated, which is nice. I can easily load it from file or manipulate in some way before it needs to be drawn, but when it comes to drawing things get uncomfortable.
The classic way would be to change data then call invalidate() on drawing wrapper,but that's inefficient for many small changes. So to, say, delete 1 Tile Id have to either have Drawn representation be independent of Data and call deketeTile() for both separately, or funnel all commands to Data through Drawing class. Things get even messier when I try to add different drawing methods via Strategy pattern or somehow else. The horror:
What wis a clean efficient way to organize interactions with Model and View?
First, definitely decouple the app logic from UI. Make some model for your schematic. That will solve your trouble to unit test the app model, as you already said. Then I would try the Observer pattern. But given that a schematic can have lots and lots of graphical components (your Tiles), I would change the usual setup for notifying every observer when something changes in the model, to notifying only the corresponding GraphicalComponent (Tile), when a Component gets changed in the Model. Your UI asks Model to do things, and gets called back in some parts to update. This will be automatic, no duplicated calls, just the initial observer registry on GraphicalComponent creation.
I am currently looking to the most efficient way to update a line connecting two three.js objects (Meshes) , when either one or both of the objects get changed (position, rotation, scale).
Currently I have a polling method for every such connecting line , that updates its start & end based on the transforms of the two end objects, but this can get costly real fast when there are dozens of lines.
I could go with an event based approach perhaps, but this requires dispatching change events from every 3D object that changes.
edit:
perhaps some sort of scenegraph based hackery would be possible, but the three.js scene graph is just a tree, so no multiple parents etc are possible
Any pointers or better/ more optimised methods are welcome !
Thanks in advance!
I'm searching for how other extjs developers work on a UI component before the json response from the backend is hooked up and working.
Feel free to be specific with code samples of how I might toggle back and forth between live data and a hard coded counterpart.
Is there one method of hard coding a datastore that can be used by every component or does each component require variations?
How would I use a remote datastore and only swap out one field value with hardcoded data?
Sorry for multiple questions, I guess what I'm really looking for is advice on what other extjs developers have found to be able to work on and test custom views without relying on the server for data.
Thanks
For the scenario you describe, I have created a store with hard-coded data and tied a component, in my case a chart and grid, to the store. Now when I get the live data from the server all I do is update my store which in turn updates the chart.
I am not sure if this is the answer you're looking? I can certainly give you some code examples if that will add value to this answer. Let me know.