Sorry if this is not appropriate question for SO: I want to open a socket and feed data to a simple line graph as real time as possible. maybe 4 refreshes per second? A lot of google searching and not much has turned up wrt how to handle this. is this possible with recharts? is it just a matter of making a custom refresh function?
There is not just one answer to your question because there are a lot of ways of doing this. Right now I'm doing something similar, so I'll use that as an example:
SignalR connects to my server and re3ceives real-time updates.
Update is stored in Redux (you can use any other datastore).
Graph component is connected to the store.
When data is updated, graph changes.
In this case there is no refreshing limit, the bar updates the moment the data comes in. You don't need any sort of refreshing function. Hope this helps.
Related
Context
I am learning Nextjs which is a framework for developing react applications quickly by providing many functionalities out of the box such as Server Side Rendering, Fast Refresh and many others out of the box without any configuration. It also provides a functionality to optionally generate some web pages statically which are pre rendered at build time instead of rendering on demand. It achieves it by querying the data required for the page at build time. Nextjs also provides an optional argument expressed in seconds after which the data is re queried and the page re rendered. All of it happens on page level rather than rebuilding the entire website.
Problems
We cannot know in advance how frequently data would change, the data may change after 1 second or 10 minutes and it is impossible to know in advance and extremely hard to predict. However, it is most certainly not a constant number of seconds. With this approach, I might show outdated information due to higher time limit or I might end up querying the database unnecessarily even if data hasn't changed.
Suppose I have implemented some sort of pagination and I want to exploit the fact that most users would only visit first few pages before going to a different link. I could statically pre render first 1000 pages, so the most visited pages are served statically without going to the database whereas the rest are server side rendered. Now, if my data might change frequently, I would have to re render the first 1000 pages after regular intervals and each page would issue a separate query against the same database or external API which would cause too many round trips. I am not aware of the details of Nextjs but I suspect this would be true because Nextjs does not assume anything about the function which pulls the data and a generic implementation would necessitate it.
Attempted Solution
Both problems can be solved by client or server side rendering because the data would be fetched on demand but we lose the benefits of static generation specifically serving static assets compared to querying the database. I believe static generation would be useful if mutations to my data happen infrequently most of the time but we still want to show the updated information as fast as we can when it becomes available.
If I forget about Nextjs for a a while, both problems can be solved by spawning a new process which listens for mutations to the relevant data and only rebuilds those static assets which needs to be updated; kind of like React updates components but on server side. However Nextjs offers a lot of functionalities which would be difficult to replicate, so I cannot use this approach.
If I want to use Nextjs, problem (1) seems impossible to solve due to (perceived?) limitation of Nextjs which only offers one way to rebuild static pages, periodically re render them after a predetermined time. However, (2) can be solved by using some sort of in memory cache which pulls all the required data from the data store in one round trip and structures it up for every page. Then every page will pull data from this cache instead of the database. However, it looks like a hack to me.
Questions
Are there other ways to deal with the problem I might have have missed?
Is there a built-in way to deal with problem (1) and (2) in Nextjs?
Is my assessment of attempted solutions and their viability correct?
Im very new to Tm1 and have to implement a new function in my code.
Is there any way to undo your last action?
For better understanding ill write an example:
I have 8 different cubes and i will upload one after one.
If one cube is not able to be uploaded all the others shouldnt be uploaded too.
Every cube which is already being uploaded should get a reset to the previous state.
Is there a way to implement it?
You have to inbriquate your 8 loading process in a master (others are slaves). If you have a condition that make one or your cube unuploadable you use the ProcessError function. In the master process, you fetch the result of the execution of each slave process. If one is in error, you use the processerror function (in the master). All the chain won't be commited.
The answer above from Wuzardor provides an approach using TI processes but your question seems to suggest you're using TM1py/Python to do the upload to TM1, either directly, or by triggering TI processes through the REST API.
In general, there's no easy way to roll back changes to cube data. However, it should be simple enough to structure your Python code such that the existence and validity of all the load files is established before you push anything to any of your cubes. It's difficult to suggest the best approach without more details about what you're trying to achieve and how.
Updated in response to OP comment:
OK, while it's not clear what IT isn't cooperating with, but if you are unable to verify the source prior to extracting it, you can always load it first to a staging cube, where the data can be checked, before copying anything to your main cubes. Depending on what issues you tend to face with the data, you might be able to automate this check or might need to rely on a human looking at it. Either way, just don´t overwrite your historic data until you've checked the new data.
Furthermore, you might want to think about your overall design. Might it make sense to retain a copy of the previous data in the cubes anyway? Why not build your cubes such that you can keep the history, rather than re-overwriting each time? Finding a sensible design really depends on the details of your application but you might benefit from looking at it with fresh eyes.
Cheers
Alex
Several months ago I met a flux and I found it's awesome, I love it, I use it.. almost in every new project and when I met a redux I love it even more, but couple of days ago Pete Hunt publish a tweet where he judge the people to use flux for everything. And I think it have a perfect sense, but on the other hand I don't get it.. He publish another tweet where explain cases for flux, also I read an article about use cases for flux. Long story short - "If your app doesn’t have complex data changes and caching, don’t use it. But if it does, I strongly recommend you try Flux." and it's totally make sense for me why I should use flux, but it not clear to me why I shouldn't if I don't have a complex data changes.
In the article Dan point, that when you faced those issues(that flux solve) in real project you can easier to understands the benefits of the flux, but exactly of this(cause I faced with these problems at work project) now I try to use flux in every project, because I don't wanna to deal with it anymore.
And crazy part, that now I often use it also for ui states, not just data changes. Let's pretend I can have a widget component, for example a clock. It can make some ui changes, like show/hide seconds, switch between digital/analog and it has a daytime type state(day/night) and can dispatch an event when it changed, but other component listen it and can react, for example change a background color. I can easily solve it just with local component state and container(smart component) state, but same as I can put all these logic into store(reducers) and components will be really dump and just react on the current state(props) and containers(smart) just listen the store and partitioned state between the components. And if even it looks ok, point that I can use it for every ui state - open/close sidebar, some specific component changes, etc.
Reasons why I can do it:
It looks predictable for me. I completely know that any changes happened in my app serve in one place.
It easy to debug. I can just log all the actions and if I will get some bug, I can easily found what happened and reproduce it.
I can easily expand my app without worrying, mb I should move something to the flux state, cause I already did it.
But also I agree that it's looks overwhelmed and I can solve it without flux, but I can't answer to me, why I shouldn't use flux in these cases. What is wrong with it? Please help me.
I'm facing a really huge issue (at least for me). I'll give you some background.
I'm developing a mobile web app which will show information about bus stations and bike stations in my city. It will show GMap markers for both bus and bike stops and, if you click it, you will have info about the arrival time for the bus or how many bikes are available. I have that covered pretty nicely.
The problematic part is loading the stations.
My first approach was to load the whole amount of stations at page loading. It is about 200 Kb of JSON plus the time it gets to iterate through the array and put it in the map. They are hiddenly loaded so, when the users click on the line name, they appear using the 'findMarker' function. If other stations were present at the map, they get hidden to avoid having too many markers in the map.
This worked good with new mobiles such as iPhone 4 or brand new HTC but it doesn't perform good with 2 years old mobiles.
The second approach I thought, was to load them by request, so you click on the station, they are loaded to the map, and then shown but this leads to two problems:
The first is that you may be (or may be not) perform several requests
which may ends the same (?)
The second one is that to avoid having so
many markers, they should be hidden or deleted so you may be deleting
info that should be needed again in a while, like bike stations that
are loaded as a group and not by line.
Finally, I thought about using LocalStorage to store them, as they won't change that much but will be a huge amount of data and then, a pain in the ass to retrieve them as they are key-value, and also (and I'm not really sure about that) I could find devices with no support of this feature having to fallback to one of the other options.
So, that said, I thought that may be someone faced some similar problem and solved it in some way or have some tips for me :).
Any help would be really appreciated.
The best approach depends on the behaviour of your users. Do they typically click on a lot of stations or just a few? Do they prefer a faster startup (on-demand loading) or a more responsive station detail display (pre-loading data)?
An approach worth investigating would be to load the data by request but employ browser caching (ETag and Expires headers) to avoid retrieving the same information over and over again. This would solve both your concerns without dealing with LocalStorage.
See this this question for different approaches for browser caching ETag vs Header Expires
Rather than using a "save" button on a web form, many web designers like a "save as you go" approach. Where as the user's changes to the data are saved immediately once the user changes focus out of say a text box.
Has anyone identified a formal pattern for this technique? I especially need to tie it all back to chunky service call. Concurrency issues seem to be one of the first issues coming to mind.
Ajax Patters has the Object Persistence pattern which sounds like what you're describing.
You may also want to look at the Fat Client article regarding response issues which might arrise.
You can try the UX Partterns Explorer by Infragistics.
http://quince.infragistics.com/#/Main
This "pattern" is actually the norm for real world interfaces (the radio doesn't wait for you to hit save before applying your volume changes).
As for the concurrency, one solution is to say that server time is "real" and then use ajax to push changes to clients who may be looking at semantically intersecting views.
-- MarkusQ