HiveStats: Developer's Insight

in #hive-1679223 years ago

HiveStats: Developer's Insight

image.png

Introduction

As I do reply to some of the posts about HiveStats, you might already know that I'm the developer who is working on it, on behalf of LeoFinance. It might feel like I'm trying to steal their credit and trying to shout out to the whole universe about it; I do also feel a little like so, not going to lie. But, frankly, I'm rather a bit excited about it, that's all the reason. I was eager to do a project on Hive and working on HiveStats allowed me that even though it isn't my project. I'm excited because lots of people use it, and give feedback about it. I try to engage, fix bugs as quickly as possible to keep the illusion as if it is imperfect. So, in summary, this is the way I'm fighting my anxiety back.

I do love talking about programming concepts, I sometimes talk all day long. I did write up two posts about it last year, in the hopes of getting some engagement. While they got some votes from curation accounts, I got no reply, which discouraged me from writing any further posts. It could be because maybe my content wasn't up to the standards, or it was too abstract. Fast forward to 2022 and I now have the experience of developing an already existing app from scratch, which is less abstract and more practical, and popular, of course. So, allow me to share my shortcomings, struggles and solutions to those, so to call my experience, while developing HiveStats. I do apologize to all of you for my brashness for using this HiveStats popularity as an opportunity.

Lack of Documentation

image.png
(searching what rshare means and its denominator)

I struggled with documentation the most, this was the most time-consuming issue by far. Documentation on Hive API methods was ok, but I can't say the same for the formulas and terms. To overcome it, I scraped example applications in the documentation, checked open-source projects that I know of, read lots of old discord messages. My Hive Engine experience was also similar.

I do plan to develop a handbook kind of website with search functionality due to this, to help other people like me.

Account History

image.png
(showing partly loaded analytics)

Most of the stuff is calculated through parsing accounts' operations over time. For inactive account's like mine, it is just a simple call; but for people like @taskmaster4450, it gets dirty pretty quick. The thing is, reading the history is limited to 1000 items per request. There isn't a way of reading a week of history or month, so results of requests are read to figure out if it's past a month or not. Using that way, getting 50 history requests becomes sync as each request depends on another.

It was an issue of the old iteration of HiveStats, which I did solve in the V3 update. I did also improve upon it in the current iteration. The trick is making them partly async. Without boring details, I do predict how many requests it would take by using the first several requests. Later, I fetch them in batches. If they overshoot, I filter, if not, batch again. That way, it becomes several sync requests of async rather than all sync.

Curation Rewards and Operations

chrome_20220212_083105.gif
(scrolling through 1657 rows)

Visualizing lots of data without combining them into something, like a chart is demanding. Rendering several thousands of complex elements as rows of a table takes time. Updating it on the go several hundred times makes the framerate unstable. It doesn't matter how fast it is fetched or parsed, if it feels sluggish, that's a bad UX. I did solve this by using a technique called windowing. So, rendering only the parts user is currently seeing, and reusing old elements in the process. While doing that, simulating scroll behaviour and memoizing heavy renders is also crucial. That way, it creates an illusion of lots of items, in reality, showing only a dozen of them.

Mobile Support

chrome_20220212_083411.gif
(simulating narrower screen view)

Mobile support is hard, making tables mobile friendly is harder. I struggle a lot to fit every bit of information on the tables, without horizontal scrolling. I did reduce the font size, used abbreviations, cut most of the title on lower screens to fit everything. While the execution was easy, it took lots of time to test and figure perfect values.

Making it Feel Reactive

chrome_20220212_083617.gif
(fetching post data while updating the table)

As I said in a previous paragraph, if a UI feels sluggish, that's a bad UX. In the frontend world, the most important thing is controlling how a user feels. Websites with more features might get lower traffic due to how they act to the user's actions and vice-versa. For HiveStats, unlike other sites, loading an account is the most important action of the user, so making it reactive was necessary. The difference between V3 and V4 is not much in terms of raw speed, but as the latter feels more reactive and updates constantly, it makes the user focus on updated data rather than waiting for it. That way, it cheats badly, creates the illusion of being far faster. That's the power of UX. React's one-way data flow and using memoization was crucial in this process.

Important Techs/Libraries I Used

  • TypeScript
  • React
  • TailwindCSS
  • React Router
  • React Virtuoso
  • DHive
  • Formik + Yup
  • Immer
  • date-fns
  • nginx
  • Docker

So, hope you like it. I tried to not be boring while providing enough data and making it a quick read. If you have any questions, I am happy to reply to all of them. See you later, thanks for tuning in!

Posted Using LeoFinance Beta

Sort:  

Multi-container thread chain.

You did a great job mate. Love the new Hivestats. Now I can easily have a good look at my hive portfolio, all in one place.🔥

Posted Using LeoFinance Beta

Testing

Posted Using LeoFinance Beta

test
Posted Using LeoFinance Beta

comment add test

Posted Using LeoFinance Beta

comment add test 2

Posted Using LeoFinance Beta

hey, test

Posted Using LeoFinance Beta

test, another one

Posted Using LeoFinance Beta

test

test container

Hello, i found this most interesting. I am working to create a small TCL library that works with the ap.hive.blog .. I have figured much out.. but like you have run into many problems with the documentation being less than complete, or rather lacking in details that would help you understand what is happening.

What I hope you can help me with is a figuring out what is the estimated curation rewards on votes given.

I've found so many values, but can't find the formula for this.

It requires multiple calculations (at least it is how I seperate them from eachother), so it would be hard to explain it here. Do you have Discord? You can add me over there: Belial#6132

If not, no worries, we can communicate in other ways. Though I'm going to sleep soon, so I'll be away for 10 hours 😄.

Loading...

Multi-container thread chain.

test container2

test container3

Multi-container thread chain.

It sounds like these are probably issues most people writing up the UI will probably face when dealing with blockchain data (you can't avoid reading the history). Have you thought of writing up some documentation on the stuff you did use for other people? Maybe just a few blog posts here and there might be able to help people and later someone can put them up together for everyone else.

Posted Using LeoFinance Beta

Yes, definitely. I did mention it as "handbook", in one of the chapters. I do really think of doing that kind of, easy-to-reach documentation. 😁

At some point it would probably make sense to look into changing this into a HAF app. That would have eliminated all the issues you had with account history fetches and batching, because you would have a database that you could create custom queries on. It does come with storage costs, of course (unless you get someone to host the HAF server for you and run your app there).

I was thinking of using the browser's local storage to cache data to reduce the burden on the nodes, before seeing HAF. Though, I do have a bigger issue going on right now. Each pending curation reward is calculated by using get_content, so that equals thousands of calls to the node. I guess HAF also could solve that, right?

Yes, you would be able to create your own API calls, so you could create a single call that met your needs. If your app is already dependent on a lot of hivemind-based API calls, one option would be to use the HAF-based hivemind that we'll be releasing soon, then adding your own custom call support to that.

Yeah! , but I see the team is working tirelessly to put out a better product. But I feel at first trial they did a good job and as time progresses they will definitely improve. Are you a programmer mate? Mehn your post was mind blowing.

Posted using LeoFinance Mobile

Yeah, I'm a programmer, though I prefer the title "software engineer" as my skillset is generic. I'm not sure but it looks like there is a misunderstanding going on. I believe you mistook this as a review, but it is actually a devblog! 😅

Oh, thanks for the clarity!

I did write up two posts about it last year, in the hopes of getting some engagement. While they got some votes from curation accounts, I got no reply.

That's a shame as the work that you have done here is amazing and deserves recognition. There are a few people that i follow who put up similar post about development and programming but it does go above my head.

Without any knowledge of programming all i can do is appreciate the final result and hive stats is an amazing piece of work.

So well laid out, so reactive, so useful. Congrats on the achievement and its worth a little brag when you hit a winner.

I know from other teams that have tried building projects that it can be tough to develop on hive as there is not as much support documentation compared to the likes of Ethereum. Will this be made easier with the upcoming HAF project form blocktrades or do we need people to take the time and put together the content for others to use?

Posted Using LeoFinance Beta

Thank you so much!

There are a few people that i follow who put up similar post about development and programming but it does go above my head.

I'd like to follow them if you remember their names.

I know from other teams that have tried building projects that it can be tough to develop on the hive as there is not as much support documentation compared to the likes of Ethereum.

I never worked with Ethereum, though I believe there should be lots of volunteer work on documenting things due to its popularity. Contrary to that, Hive requires you to know someone who already knows about it. It would be much harder for me without me asking my friend every day about the Hive.

Will this be made easier with the upcoming HAF project form blocktrades or do we need people to take the time and put together the content for others to use?

The only thing that I know that's related to HAF is history revamp. So, I can only guess that documenting the new and easier to use API be easier on their end too.