So, I'm creating a SQL Server versioned project. We have targets using Windows, Linux and are moving to a containerized environment for testing. SQL projects in Visual Studio can only be built in Windows and we've had some troubles with version conflicts (several customers and internal deployments and growing). So moving to a number list of version scripts... we need a way to run it with all of the above environments.
I created the above module to better support those use cases for script deploys. The export scrips (baseline) from the sql project will only really run via sqlcmd, not to mention issues with UTF8/16le, and windows uses -v for variables and linux uses environment variables... this handles all of those use cases.
About a week of very heavy work with thorough test coverage (about 5 files, mostly small/simple utilities are excluded). There's also a set of integration tests that will create a docker container, and populate it with both a local sqlcmd (if available) and the sqlcmd inside the sql server container instance.
I would only suggest one change in the article, and advice to anyone using this... always have a separate action item on screen for this. A copy button, next to the text, or if a textarea an overlay or above or below.
Having the copy action on a click trigger will be unexpected behavior. Click on the text should probably do a `.select()` of the entire field though, but not copy to clipboard. A separate action should be doing that.
edited the title to match the Repo Description...
Some of the hooks may well be very useful, I've seen quite a few. I'm not the downvote, but the clickbait tile was probably the reason.
Would probably suggest a followup on using ES, Kibana and Filebeats from within a container... you can pass the docker socket to filebeats running in a container, and locally, since you're unlikely to cluster, having ES in the background with Kibana is probably easier to set/reset.
The key seems to be...
import * as React from "react";
import { GridLayout } from "@egjs/react-infinitegrid";
Note: this looks to add about 180k of gzipped JS on top of React's baseline, the demo is about 252K gzipped. Definitely not a *light* implementation in any way, shape or form. If this is the bulk of your UI, it may not be so bad... I generally try to stay under 500k total gzipped JS payload for web applications.
https://www.npmjs.com/package/@egjs/react-infinitegrid
https://github.com/naver/egjs-infinitegrid
I've always thought the UX for the date picker from the MS Ajax Toolkit is about as good and intuitive as it gets, it looks like the bootstrap-datepicker implements this... unfortunately, it also requires jquery+bootstrap, and if you aren't using bootstrap to begin with, it's too big to bring in just for this. Range pickers are also easy to get wrong.
In any case, for the most part, just use input type=date and rely on the native interface for picking a date. You aren't adding a bunch of extra overhead, and it should be the expected experience.
The key seems to be... import * as React from "react"; import { GridLayout } from "@egjs/react-infinitegrid"; Note: this looks to add about 180k of gzipped JS on top of React's baseline, the demo is about 252K gzipped. Definitely not a *light* implementation in any way, shape or form. If this is the bulk of your UI, it may not be so bad... I generally try to stay under 500k total gzipped JS payload for web applications. https://www.npmjs.com/package/@egjs/react-infinitegrid https://github.com/naver/egjs-infinitegrid