With the exception of Parcel this is pretty easy to do. The end user needs to tell their bundler to transpile node modules. The downside of shipping Source is that browser only environments can't handle it. With the source things could continue to work across many versions without breaking. JSX syntax changes a lot slower than compiled output. It also doesn't tie your library to a version of the compiled output. You would still need to include the babel plugin for testing but JavaScript source could basically stay as is without any bundler or build step. Even TypeScript users only need to run tsc to output JS and types with jsx: preserve and they are done. The upside of shipping Source is that it is incredibly easy to author. So it's possible that 3rd parties won't need to use special exports for the most part. So anything you need on first render only can be safely placed here and won't end up in your client bundle even if compiled from the same source.
#HYBRIDSJS UNPKG CODE#
However, what I've done with solid-js/web is expose static isServer booleans so that smart bundlers like Rollup can automatically dead code eliminate any isServer code branches from our client bundles. browser and server keywords along with node allow us to select the right bundle based on the environment.Īny 3rd party library could use the same convention to ship different bundles. I already use this to great effect with solid-js/web which depending will import different versions. Secondly, conditional exports in package.json allow us to alias builds based on a keyword. However, this still at best leaves us with 3 different outputs at a minimum if we assume server-rendered is always hydratable. I am in the process of combining the server bundles into a single compiled output and single runtime. This is a lot for a would-be third-party developer to consider.įortunately, there are some things in the works and there is some tooling that can help us here. We have our typical reactive client, and then the 2 different server models. Solid at runtime has different runtimes based on the environments too. If you are keeping track that's 6 different types of output before considering ES6 modules vs CJS. Are we outputting for client or for server? Is the output hydratable? Today we even support multiple types of SSR generation based on whether we want to use the reactive system on the server as well. This JavaScript differs based on compiler settings. At build time we compile our JSX into optimal JavaScript. Solid is a hybrid solution of runtime and build time JavaScript. The question is: Should Solid libraries be exporting precompiled code as you find in React or the direct JSX templates like you find in a library like Vue or Svelte? Background I'm thinking I'm either on the right track or I need to add a new HybridAuth method to detect and store data for all or specific connections that already exist.I've been debating this for a while and now that I've gathered my thoughts I'd like to request some feedback from the community. (I even removed the "die() " at the end of the redirect() function to no avail.) My Javascript includes something like this: FB.init(," to the Ajax call and tried to modify HyrbidAuth to not redirect if it $_POST existed. So in the middle of the GetProviders function of the Hybrid_Auth class, I added: if(array_key_exists('keys', $params) & array_key_exists('id', $params))
I started by including the configuration IDs in the data I pass to the View so I can use them when calling Javascript login functions. Starting with Facebook, I'm trying to use the provider Javascript SDKs to login and have HybridAuth "know" about it.
(repost from !topic/hybridauth/CWo2R9suYts)
0 kommentar(er)
