My ongoing frustration with code reuse in general is that the code I'm looking to reuse reuses other code that reuses other code that refuses other code that reuses... it's turtles all the way down, and any of those turtles can throw a completely opaque error message that required very deep knowledge of that particular turtle to make any sense of. I applaud, thank, and appreciate the author for going back to basics.
As someone who writes React every day, I'm not sure how the `react-dragula` implementation even remotely constitutes React integration? AFAIK React never made any guarantees about `data-reactid` nor what it means to remove it? It's not a public API and is not even used in the latest React anymore except for picking up SSR'd markup? I have serious doubts and wouldn't go anywhere near this.<p>Secondly, if you tout "React integration" people are going to want a Draggable component or mixin/HOC or whatever. Making people do things in `componentDidMount` isn't really integration.<p>That said: yes, it's a good idea to base your framework-specific integration on top of a generic battle-tested library. This however appears to be a bad example of that.
I like this approach, but one problem with plain javascript that I haven't heard many people address is testability. A module I am using with angular has lots of calls to setTimeout, but these timed out functions are sometimes not invoked until after a test had cleaned up the DOM in preparation for the next test. The timeout function fires and then throws an error because none of the elements it expects are on the page.<p>Libraries that set a lot of native key handlers can also be problematic. Native browser key events are a pain to mock, and the same mocking techniques are not available in all browsers. If you want to unit test in all browsers, you have to write some truly hideous tests.<p>The fact is that a lot of browser API's are terrible, and tools like jquery can help smooth over browser differences and make it easier to test your code that relies on a library.
Why is atoa() being used on arguments? You can pass an arguments object to apply(). It even avoids deoptimization (at least on V8), IIRC. (No explanation at <a href="https://github.com/bevacqua/react-dragula/commit/916c5fe4900eca47c07e139d1e0783ca7c6ba814" rel="nofollow">https://github.com/bevacqua/react-dragula/commit/916c5fe4900...</a>)
I do exactly this now. I used to write "Angular Directives" but not everything I want to share is in pure JavaScript.<p>Here are some of my successful pure JS modules:<p><a href="https://github.com/mohsen1/json-formatter-js" rel="nofollow">https://github.com/mohsen1/json-formatter-js</a>
<a href="https://github.com/mohsen1/json-schema-view-js" rel="nofollow">https://github.com/mohsen1/json-schema-view-js</a><p>If you want to use those modules in any framework you just wrap it in a tiny thin wrapper and I don't have to keep up with framework changes and all that...
I agree in general, but in the space of UI frameworks it's hard if not impossible to write good cross-framework code.<p>Most frameworks have a specific way of rendering the DOM.<p>In React, manually altering the DOM is an anti-pattern. Even more so if you are using a global store like Redux and/or functional components.<p>Integrating other "classic" UI code into React is almost always very hackish.
I've been advocating this for a while, business logic should not be tied to a specific framework. It can be brought into any framework with a super thin, easy to write/read wrapper.<p>But UI level stuff, probably should be done in your framework. So Business logic drives state, which your framework translates into DOM.
It's hard (not impossible) to avoid this with some user interface code, due to the amount of connected, stateful cruft (hopefully the state is pushed out to the edges, but it has to be there somewhere).<p>I do appreciate little utility libraries like Ramdajs and Validatejs, though.<p>This article was a nice reminder to make the attempt to decouple small plugins, though. I like the idea of the base module + alternate framework adapters.
Just yesterday I spent 4 hours looking for something that'd let me use DOM queries with map and forEach. I settled on NodeList.js. I didn't want JQuery or Zepto or anything larger than 1 KB, but I also didn't want to write something to do this, something I'd have to copy and paste into the next project.
Yet another reason why moving to Web Components will make everyone's life easier. No need for these framework-specific binding layers. It's just DOM.
> The point in question is that developing a library that specifically targets a framework is a waste of your time, because when you eventually move on to the next framework
( this isJavaScript,youwill) you’ll
kick yourself over tightly coupling the library to the framework.<p>How about not targeting a specific language either?