You can use Airbnb's Sketch to React app to convert your Sketch designs to real React components. There's also a Sketch to HTML app if you need HTML and not React components.

You can drag these components into your React app and play around immediately. Usually people combine that tech with Storybook, so you can browse a live library of your components.

I'd also consider watching for Wordpress and their new Gutenberg release. They're adding React components to Wordpress to replace the classic text editor for posts, so you can drag and drop React components to create pages. This is the easiest way you'll get to "drag and drop" React apps without setting up your own framework/build process.

Simple, don't use react.

Not a joke. You're just making it more complex than need be, and possibly telling users with accessibility needs to go plow themselves.

Telling visitors to your sites to "sod off" NOT being a great battle plan. My consulting contracts of the past five years all involve ripping stuff like react OUT of websites where it has utterly screwed over the site owners. To the point many of them were in COURT over accessibility issues!

... much less if you're making a web page "sketches" and "drag and drop" are the antithesis of accessible web development. Universally any such tools that provide that capability are nothing more than giant scams trying to saddle you up and take you for a ride. There's a reason nobody who cares about UX or accessibility would use a WYSIWYG editor or consider paint programs like Photoshop to be a design tool.

No matter how many artists under the delusion they are designers will claim otherwise.

This is because websites are for MORE than the perfectly sighted user sitting in front of a screen. The underlying technology of HTML is designed first and foremost for "device neutral" delivery of content. This is why HTML tags have semantic meanings SEPARATE from their default appearance. As the saying goes, "If you choose your HTML based on what you want things to look like, you're choosing all the wrong tags for all the wrong reasons".

When TBL created HTML the whole idea was to deliver content to EVERYBODY regardless of device or personal capabilities. That's why P is for grammatical paragraphs and not "oh here's some text" -- a lone IMG is not a paragraph. A LABEL + INPUT are not a paragraph. It's why (unless you use HTML 5's garbage SECTION tag) THE (singular) H1 is THE (singular) heading (singular) that everything on every page of a site is a part of, why an H2 indicates the start of a major subsection of the page, why an H3 indicates the start of a subsection of the H2 preceding it, H4 are the start of a subsection of the H3 before it, etc, etc down to H6... with even HR meaning a change in topic or section where a heading is unwanted or unwarranted. They DO NOT MEAN "fonts in different weights and sizes" or "draw a line across the screen"

...and anyone telling you that's what they mean has no business telling you the first blasted thing about HTML! See such nube predator scams as W3Schools or Bootstrap.

That way things like screen readers, braille readers, search engines, and other non-visual user-agents have something to work with.

You're not going to get that with "drag and drop" or a WYSIWYG.

Start with your content or a reasonable facsimile of future content in a flat text editor as if HTML doesn't even exist and arrange it in a logical order. THEN mark it up semantically. THEN apply your screen media style, THEN create other media targets (such as print) if desired. THEN enhance it with client-side scripting...

Once you have all that completed if you insist on using react, chop that markup up into the appropriate sub-pieces and plug it into the framework or whatever other back-end you're building for.

... or at least if you care about visitors to your pages actually using the site that's the best approach.