JQuery to React: How we rewrote the HelloSign editor
dropbox.tech
dropbox.tech
The problem is they have three things that they want to be the same but aren’t, and the solution is to rewrite so the significant parts can, in fact, be the same. React and jquery are details... that is, you can have the same problem and same solution with different details.
I also wonder if this particular approach will end up being successful for them. Can’t the editor, signer and final pdf all be rendered by different browsers and different versions of browsers? IDK, maybe it’s close enough for their cases or there is a strong filter on input that limits this to elements that render consistently enough. Or maybe this is a “must use updated Chrome” app?
Databases don't dictate the structure of your entire application like a framework does, so that comparison is not useful.
I'm not really sure what you're trying to "protect" from React in this case? It renders what you tell it to. From a component perspective, whatever the output of your component is, that's what gets rendered/updated on screen. There are a few escape hatches in place, depending on what you're trying to do though.
From TFA examples, when faced with similar issues (though not quite the same), I found directly writing SVG markup over a document background to be extremely straight forward with React.
For the most part, the problem you are describing is when you are actively trying to NOT use the tool you're using. I've been developing web based applications since the mid 90's and React is hands down the best tool I've used in that timeframe for web applications. That said, if you're mostly delivering static content, then it may not be the best fit. In those cases using something like Vue, or another option for enhancements (even jQuery-like) may be a better option.
If you're going to use React, you are best off understanding and embracing it... if you aren't, then don't use it. I don't intend to be mean, it just seems your perspective is off. It's much like asking how you use a SQL oriented database without the inconvenience of SQL or data types.
As to variations in rendering, for some things like this, there isn't that much different. A project I work on at work does similar overlays with scanned images for marking up manual verifications and creates a final composite document in a similar way (react fe, .net core be).
> A software engineer’s job is not to write code, it’s to solve problems, by writing code when necessary.
This is a good litmus test to detect the presence of a senior developer.
The user doesn’t care who wrote what code but they sure as hell care about quality of product. If you want to differentiate a developer is going to have to get their hands dirty with an original solution as the situation demands.
It has nothing to do with letting the user know who wrote what code. It is all about quality of product like you say. For example, less code means less opportunity for bugs. And, using off-the-shelf solutions means more support resources will exist. Off-the-shelf solutions also let you draw on the knowledge of experts in that space rather than reinventing the wheel.
Remember what I said earlier: UI is a functional representation of state.
I don't really see how making that particular pattern more convenient would be a radical game changer.
Except they don't, so the whole blog post should be taken with a grain of salt.
I just signed a document a few days ago (on Sept 28th). I didn't like the default font for signature they offered, so I picked some other, script type of font. Everything was fine until I saved it. And suddenly, the signature switched to some completely different serif font.
The document wasn't really that important to me, so I let it go like that, but doesn't look like something I would trust currently.
EDIT: HelloSign people are obviously reading this. Instead of down-voting me, the proper approach would be to ask for details and fix your bugs. For example, I just tried another document on Windows and it worked properly. For the problematic one, I was using Firefox on macOS, so maybe you should look into that. I can also send you the document ID hash if you ask nice.
With that lot, the assumption isn't much of a stretch.
That's rather presumptuous of you, as it implies your goals are more correct than anyone else's.
Perhaps next time the following would be more accurate:
> The 'proper approach' for me would presumably be to report this bug to them directly
I do that for products where I'm a customer and I actually care about using. I got to sign that HelloSign document because one of my business partners requested it, so if anyone should report bugs, it would be them. This was my first time using HelloSign, and it left a bad first impression.
I just find it amusing that they are bragging on top of HN about a product feature that doesn't even work properly.
> rather than assuming that downvotes are coming from the company!
Who else then?
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like.
> Please don't comment about the voting on comments.
Me.
For visual consistence just stick with templating model and SSR. Also most tech people mostly turn off JS when they browse the web any way. React people, yes I'm looking at your!
In addition, as React/Redux type of projects gets big, it is a nightmare to maintain. Yes I know it is all about the coder. However, most front end developer (transitioning from jquery css/html) do not have the needed programming skills to develop something like React.
I would say React is more computer science ppl who wants to do front end approach. If that is the case, just go with mithril (they have JSX). Stop this insanity of using React just because hipster sillicon valley ppl are using it cause it is trendy and get high paying jobs.
any public stats that confirms this?
Tree models.
Many developers have trouble understanding implicit relationships present in tree models. That is a cognitive barrier acting as a breaking force that eliminates any development. To solve for that frameworks provide an abstraction layer so that developers can envision the DOM more as a graph to be searched.
There are all kinds of performance penalties for superficially reinventing a technology like this, but the bigger limitation is lost creative potential. Instead of operating according to the capabilities of the language or API the developer is operating according to the limitations and most common approaches of the framework. For example templating is mostly easy. State management is ridiculously easy. But, the frameworks would have you think these are massive accomplishments requiring the titanic efforts of a super genius.
Seriously, there’s so many fake outlandish claims in this. Most tech people do not turn off JS because they know most of the web will break. They also know React projects scale really well and React is not a trendy project.
You ran into a bug in some web software. It happens. Sounds like it was already fixed.
Meanwhile, the above blog post is a pretty amazing technical breakdown that is extremely detailed and well constructed. To reduce the entire company down to "a joke" because you ran into a bug once is just rude and dismissive. You might even agree because you changed your comment, although you still found a way to insult the blog post and the author.
And no, I don't work for Hellosign. I'm just a software engineer with some empathy for the hard work that has clearly gone into this. This is great knowledge sharing. Time and place.
Yes. I changed it like 5 seconds after posting. Even tried to create a new document to show how it failed, but it was on a different computer and I couldn't reproduce it here. It's probably a browser/OS combination.
> And no, I don't work for Hellosign.
Well, alright then. But you aren't the only one. The score on it has had many ups and downs today.
Their job is to provide an authoritative and trustworthy record.
This is quite serious if these documents are to be used in litigation. Generally I'm happy with best effort, but in the case of this situation where a reliable record is required, they've dropped the ball.
In this case it seems they make a "best effort"(not guarantee) to offer uniform document display across browsers and OSes, which suggests they may only test the most popular browsers and OSes, and edge cases like Firefox on macOS may not get much love.
It depends on the software and its purpose. Signatures are very serious business. They carry with them enormous legal weight and not getting them 100% right can have massive repercussions. Therefore, it’s all about trust. So then the question becomes, if trivial bugs like this were not caught during QA, what else must have slipped through?
I would trust that more than various pdfs ....
I assume that's just me
I believe Vue is just kind of Angular for React developers who don't like angular (usually due to fact that it involves reading docs on RxJS and angular modules)