profile-hover icon indicating copy to clipboard operation
profile-hover copied to clipboard

Profile Hover React Component

Open zachferland opened this issue 6 years ago • 2 comments

This issue for creating a re usable React Component that can be easily used in the same spirit as the current plugin. Minimal lines of code and out of the box defaults.

Some thoughts about it so far or some issues to resolve that make the current plugin difficult to use in a react app.

Managing State

  • state should be sandboxed from other app state
  • needs to store/cache api call data for some time, don't want to call API on every rerender
  • only input state should be configs, what the best way to pass in? probably props

Isolation

  • exception/error from this plugin should not crash entire app, How to isolate from the rest of the app?
  • npm install, and minimal code to implement, may need to preprocess build parts
  • Isolate css/html, something like css modules or just name-spaced, css classes/id should be unique to avoid styling conflicts, but deterministic if someone really wanted to modify an element

Reuse / Modular

  • Make as much code re usable as possible between react component and current profile hover. Some is already modular. Rely on build processes to put it together or process from one context to another. This is mostly for future maintenance, and could have other plugins in differing forms in the future. Also open to changing structure of current plugin to make more re usable components. To counter points above, lets not over optimize, if its too difficult to re use some parts across both, lets just separate for this iteration.

Scope

  • Meet same functionality styling as current plugin. New features, styling, configs, etc will be added to other issues.

Related Issues:

  • First thought - https://github.com/3box/profile-hover/issues/11
  • For our first implementation in our own site -https://github.com/3box/profile-hover/issues/15

This is largely open for interpretation, and open for suggestions on the best way to implement. I have not implemented a re usable react component as a npm package and have not worked with react in a while, so likely others will have better input.

Can use this issue and/or discord to discuss everything around implementation, and mention here if you are working on it.

zachferland avatar Apr 30 '19 17:04 zachferland

Looks like a good plan! A few questions:

  1. Regarding cache, is the idea for it to work as it does now with a cache that is consistent between page reloads? Or should it just cache the data in the react component state, which would mean that the data will have to be fetched the next time the component is mounted?
  2. I think a good solution for the CSS would be to use CSS-modules as in the current implementation, but remove the hash from the produced classes and add some namespace prefix to make it both isolated and deterministic. Does that sound like a good idea?
  3. I see two possibilities for the HTML, either JavaScript template strings just like how it is implemented now. Or using JSX and use something like jsx-render to render it in the non-react build. I guess template strings would be a bit more lightweight, but JSX would result in nicer-looking code. I played around with this a few weeks ago and using jsx-render increased the build size by 11kb, so a pretty small difference. Are there any other possible solutions? Which one do you prefer?

I'll start off the work on this one. And think I will start by refactoring the current solution to separate the reusable parts and then do the React implementation. Would you like me to do pull-requests along the way to keep you more updated/involved?

raksooo avatar May 01 '19 11:05 raksooo

  1. data in the react component state works, no need to store in browser cache a the moment
  2. yup, i agree!
  3. yeah I wouldn't mind switching to JSX now, almost did in the beginning, but string literal templates provided enough, but in this context now, JSX definitely make sense (or probably any templating engine, but still would say JSX i guess since react and how commonly used now)

Another note, a lot of the CSS/HTML isnt too great, but im going to try to keep it out of scope for this iteration. With improvements there later, but of course can take note of anything obvious you might find while looking through/using the code more.

Sounds good! yeah pull requests would be great, i will also be able to contribute more in a week or so, so would like to follow. Small prs are nice, but for this im assuming the react component implementation may inform the refactor of the current code a bit, so also fine if just a single branch/PR for this with all the commits

Thanks again for starting this!

zachferland avatar May 01 '19 13:05 zachferland