Clearly state features in Readme

cphoover commented 5 years ago

Not to be a dick (and I hope I don't come off that way.) but what is the purpose of this library?

How is it any different from just doing something like this:

untested example:

<!doctype html>
<html>
...
<body>
    <div data-component="NavigationComponent"></div>
    <div data-component="SlideshowComponent"></div>
    <div data-component="FooterComponent "></div>
</body>
</html>

// bootstrap.js
const componentMap = {
    NavigationComponent : React.lazy(() => import('./NavigationComponent'));
    SlideshowComponent : React.lazy(() => import('./SlideshowComponent'));
    FooterComponent : React.lazy(() => import('./SlideshowComponent'));
};

const loadComponent = (componentName) => 
    Array.from(document.querySelectorAll(`[data-component=${componentName}]`))
       .forEach((node) => ReactDOM.render(componentMap[componentName], node))

Object.keys(componentMap)
    .forEach(loadComponent );

Perhaps it would be helpful if there was a feature list, or list of things this library does that otherwise wouldn't be possible. Does it allow for compatibility where otherwise there would be conflicts? Does it allow for multiple instances of react? What problems do react-habitat seek to solve?

jennasalau commented 5 years ago

Hey cphoover,

We have a very extensive Readme that explains all the things that are possible with React Habitat which already includes a feature list.

Not to be a dick (and I hope I don't come off that way.) but what is the purpose of this library? What problems do react-habitat seek to solve?

The underlying logic of React Habitat is no different to what you are demonstrating, in fact the starting point of this library was not to dissimilar to that the only difference being React.lazy was not even a thing back then.

You could say we have just formalised that process by building it into a framework and have since added features around it like automatic parsing of props, default props, dynamic updates when HTML is ajaxed in, etc

React Habitat has always been designed to die. We would much rather be building modern headless React with PWA's or SPA etc.. Rect Habitat exists purely for cases when we are dealing with "old" systems that render HTML that might otherwise use JQuery. i.e. You can think of React Habitat as "sort-of" modern alternative to JQuery.

. Does it allow for compatibility where otherwise there would be conflicts?

React Habitat will throw warnings where there are conflicts. https://github.com/DeloitteDigitalAPAC/react-habitat/wiki/Warning-&-Error-definitions

Does that answer, if not can you please elaborate.

Does it allow for multiple instances of react?

Yes if you have multiple containers/builds. Obviously it would be better to upgrade.

This library was more of an internal thing for us that we have shared. We are not trying to pedal it and create an amazing sales pitch. If you think we can make specific improvements to the feature list in the Readme I'm all ears.

cphoover commented 5 years ago

React Habitat will throw warnings where there are conflicts. https://github.com/DeloitteDigitalAPAC/react-habitat/wiki/Warning-&-Error-definitions

Does that answer, if not can you please elaborate.

^^ What I meant was, does react-habitat seek to remedy otherwise occurring conflicts that arise out-of-the-box with the target CMS' specified (joomla, drupal, AEM... etc). Without react-habitat would there be compatibility issues. Does react-habitat seek to fix compatibility issues?

@jennasalau Thanks for this update! What you said makes perfect sense. Just evaluating solutions for an Adobe Experience Manager (AEM) project. Honestly I could have phrased my question better. This will help in making a determination of whether or not we need to use a library like habitat.

Also thanks for supporting open source projects. It's not always easy for enterprise tech to get behind :+1:

DeloitteAU / react-habitat

Clearly state features in Readme #44