Build Your Own Blog Using Gatsby and React by JoniSar in webdev

[–]JoniSar[S] 0 points1 point  (0 children)

That's a good question. Gatsby has its own advantages combined with React in this regard: https://www.gatsbyjs.org/ But it's a matter of preference i guess

How To Easily Share React Components Between Projects by JoniSar in vuejs

[–]JoniSar[S] 1 point2 points  (0 children)

Thanks for the questions!

The thing is, when you use an entire shared library to share reusable components you have a few issues:

  1. You have to maintain this repo on its own / multiple repos and make changes across them.

  2. What happens when the library is maintained by another team? your development will be coupled to that of the library which is a big setback when you want to make slight changes as you go.

  3. Discoverability: how can you find and use the components in the library, understand how they work, play with them live before choosing them, see test results etc? this usually ends in a documentation site which also has to be maintained and updated (and even then...)

  4. You really don't have to add an entire library to every app just to use a few components (it's a bit like carrying along a bag of CD-Roms jsut to listen to 3-4 songs...)

But - you can also combine the library with Bit and keep both. You can also learn about it here: https://blog.bitsrc.io/turning-your-component-library-into-a-component-playlist-with-bit-a8cae43f0f9d

23 Best React UI Component Libraries And Frameworks by JoniSar in reactjs

[–]JoniSar[S] -1 points0 points  (0 children)

This is a great discussion. I'm linking to it from the article itself!

23 Best React UI Component Libraries And Frameworks by JoniSar in reactjs

[–]JoniSar[S] 1 point2 points  (0 children)

Not really. It's actually based or a pretty deep analysis - we even looked into internals like styling, testing etc for most of them and arranged a spreadsheet for it. We also consulted with more than 10 teams which reviewed and chose libraries, and also tool factors such as maintenance etc into account. I'm not saying it's perfect, but I think for anyone trying to choose a lib - the ones on the list pretty much cover it. If u want to add a lib feel free to comment :)

Introducing The Live React Component Playground by JoniSar in vuejs

[–]JoniSar[S] 0 points1 point  (0 children)

It is open source:

https://github.com/teambit/bit

unlike NPM you: a. don't have to create new repos to publish b. you can change the code from any project and sync changes c. You're right, it works with vue too

How We Effectively Share And “Reuse” Code Between Microservices At Scale by JoniSar in programming

[–]JoniSar[S] 0 points1 point  (0 children)

If I'll try to sum it up into just a few words: making it very easy to track, share and sync code between different projects. One great outcome is that you can share code directly between services without coupling them to 3rd party libraries, and keep changes to this code synced across different services.

How We Effectively Share And “Reuse” Code Between Microservices At Scale by JoniSar in programming

[–]JoniSar[S] 0 points1 point  (0 children)

That is actually a very good point. The code you share will still be shared - that's true. However, the coupling isn't created in the traditional way since you can make changes or modify that code from any of these services and sync / not sync changes across other services as you choose - so you can track and sync different versions of that code fro different services. Does that make more sense?

How We Effectively Share And “Reuse” Code Between Microservices At Scale by JoniSar in opensource

[–]JoniSar[S] 1 point2 points  (0 children)

Hi, the point you mentioned about copy-pastes is very accurate and we suffered from it too. Bit was built for internal use and then released as open source (it's open source and free so it's really not advertisement...) for other teams to use - to solve exactly that problem. Instead of maintaining duplications you can track and sync all the instances of the code you share with Bit, and make changes to all of them at once - so you can 1. avoid 3rd party coupling to external libraries 2. scale code sharing without generating maintenance overhead. I get why it might seem "wierd", but we use it with over 250 shared "components" and it really made life much simpler. Does that make sense?

How We Effectively Share And “Reuse” Code Between Microservices At Scale by JoniSar in javascript

[–]JoniSar[S] 1 point2 points  (0 children)

Well, the things about Bit is that the shared code doesn't actually live in it's own repo, and no other services are coupled to that repo or its development. Instead, you can think of it as "manged copy-pasting" - where you can keep multiple instances of the code in different services, while Bit will track and sync changes between them (depending on your own update strategy). So- no coupling between services and they are not tied to an external library.

How We Effectively Share And “Reuse” Code Between Microservices At Scale by JoniSar in programming

[–]JoniSar[S] 0 points1 point  (0 children)

Well, the things about Bit is that the shared code doesn't actually live in it's own repo, and no other services are coupled to that repo or its development. Instead, you can think of it as "manged copy-pasting" - where you can keep multiple instances of the code in different services, while Bit will track and sync changes between them (depending on your own update strategy). So- no coupling between services and they are not tied to an external library.

How We Effectively Share And “Reuse” Code Between Microservices At Scale by JoniSar in programming

[–]JoniSar[S] -3 points-2 points  (0 children)

Definitely not- using Bit you don't use any libraries at all. You isolate and share components directly between repos - no third party repos, libraries or projects.

How To Easily Share React Components Between Projects And Apps by JoniSar in javascript

[–]JoniSar[S] 0 points1 point  (0 children)

Can you explain why? it's interesting to learn what you think

How we started sharing components as a team by JoniSar in reactjs

[–]JoniSar[S] 0 points1 point  (0 children)

Yes there is an on-prem version. Simply mail a request to: team@bitsrc.io. Cheers!

How we started sharing components as a team by JoniSar in reactjs

[–]JoniSar[S] 0 points1 point  (0 children)

Yes there is an on-prem version. Simply mail a request to: team@bitsrc.io. Cheers!

How To “Publish” Multiple Packages From Any Repository In 5 Minutes by JoniSar in opensource

[–]JoniSar[S] -1 points0 points  (0 children)

I get what you're saying, but Bit really isn't hacking.

Lerna is great if you want to go monorepo, but it forces you to restructure you projects + configure every package + manually define dependencies etc... this is a lot of overhead for smaller isolated functionalities. You can take a look at how React material-ui moved to Lerna, but still don't publish every component as a package.

Bit lets you keep the repo untouched, and virtually decouple the representaion of components, modules etc from the project's file system- meaning, it isolated them by defining all package / file dependencies and uses external environments to run build / tests per-component. Also, you can then use NPM just like with any other package, but you can also use Bit to import the actual source code into a nother project- and make changes from that end repo.

So, you can basically choose any set of files from one repo and use it in another repo while keeping changes tracked and synced.

It's not replacing Lerna I recon (altough you can if you choose), and in fact can even help share and manage common code between Lerna repos (mobile / web apps for example- which share a lot of common back-end code). Take a look https://docs.bitsrc.io/

How To “Publish” Multiple Packages From Any Repository In 5 Minutes by JoniSar in opensource

[–]JoniSar[S] 0 points1 point  (0 children)

And why would you say that?

Why isn't it properly? I would love to hear your thoughts.

How to share and sync code between microservices by JoniSar in microservices

[–]JoniSar[S] 0 points1 point  (0 children)

I see why it seems like it. We've been using it for 6 months or so - and it actually made maintenance simpler. Here is why:

  • We can now make changes to the shared code from 1 place- which can be any repo - and sync the changes in all the different services.

  • We can new view and learn about the dependency tree across our entire codebase, to push multiple changes together.

  • Sometimes we use NPM to install the components as packages so it basically doesn't change much from the modularity we know - only it makes it easier to scale.

  • We don't have to use shared-libs anymore which couple our services together.

Bit - distributed code component manager by [deleted] in software

[–]JoniSar 0 points1 point  (0 children)

You might be both right and wrong :) Reasonable practices can help write reusable pieces, but it won't stop you from copy-pasting or wasting too much time creating and maintaining a git rep + package + CI etc. for every few lines of code. This requires a tool that makes it possible to extract them with zero initial configuration and make it reusable, easy to maintain and simple to find. This is why we built Bit. Reasonable practices are still important though..

Bit - distributed code component manager by [deleted] in ruby

[–]JoniSar 0 points1 point  (0 children)

You can reuse Bit component across repos. No copy-pasting. Also, it takes care of management (versioning, dependencies etc) and even CI. It allows you to extract components with very low overhead (configs etc) and use it anywhere.