Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Alok Kumar
    @iFlameing
    @datakurre I try to connect with Plone baseUrl using websocket but I am unable to get any response.
    I ran the command make purge init-backend command and connect the socket with the baseUrl but didn't get any response.
    Alok Kumar
    @iFlameing
    @datakurre when I am checking connection as socket.connected it gives me false.
    Asko Soukka
    @datakurre
    @iFlameing I assume from your pull that you got the websocket connection working?
    Asko Soukka
    @datakurre
    @iFlameing When you were using baseUrl, did you remember to change the protocol (http:// or https://) to ws://?
    Alok Kumar
    @iFlameing
    @datakurre I did some research about the socket problem and found that it works little different than original websocket. Behind the scene it implement lot of function on top of original websocket. By ws npm I am able to connect to the websocket.
    Asko Soukka
    @datakurre

    @iFlameing Oh, sorry about that. I did't realize that. Actually I thought that it would be only useful for the mock server (to get a server build with minimal work), but forgot to say that aloud.

    Good that you were able to move to simpler library.

    Asko Soukka
    @datakurre

    Today I worked on Plone websocket design and implementation to allow restricting notifications by user permissions. I had progress, but was unable to complete the implementation today. So it probably takes another week until I can update the project with more production ready websocket support version.

    Just tell me if it blocks your development that Plone sends notification for content that you don't have permissions. There is a manual workaround to make Plone publish all new content immediately.

    Alok Kumar
    @iFlameing
    @datakurre No, I just update the token everyday and continue to development :)
    I think that current websocket is enough for gsoc as you said earlier.
    Asko Soukka
    @datakurre
    @iFlameing For me it seems that you may have MVP (minimal viable implementation) for add, modify and delete completed pretty soon. What would you prefer doing after that? I know the code could be refactored, but for a good practise you should try to write test before refactoring (so that the tests would prevent you from breaking anything during refactoring). All the data used in acceptance tests is there already in JSON format, so unit- and integration testing everything should be possible (though not necessary easy).
    Alternatively (or after testing) there are a couple of small or medium size issues available: refactoring logging and adding image size information into images within Plone document rich text fields.
    Finally, as a large stretch goal there is anything to help porting this plugin to TypeScript.
    Asko Soukka
    @datakurre
    @iFlameing Just think about what would you like to learn most during the rest of this GSOC to maximize the benefit of this time for your experience.
    Alok Kumar
    @iFlameing
    @datakurre One feature is still left in MVP i.e Delete which I will try to implement as soon as possible. I am following your words taking each week as sprint and try to implement a feature in a week.I do not believe that I am completing a feature in a week. I am totally inspire by you, you said that you can provide me websocket on first week of june and you made a pull request on Tuesday night as you said. I am devoting lots of hour in learning code, understanding the gatsby-source-filesystem and Plone. After achieving the MVP, I think that I should write test for all the implemented feature i.e (add, modify and delete). I have some experience with jest and enzyme but not with other framework. But currently I am focusing on the MVP :)
    Asko Soukka
    @datakurre

    @iFlameing Sounds good. So, after MVP, let's figure out a way to test all these before any cleanup refactoring.

    tests for fetchUrl and fetchPlone provide an example how Plone could be mocked for testing https://github.com/collective/gatsby-source-plone/blob/master/src/__tests__/utils.tests.js#L90

    At first, the use of http library should be parameterized so that any call to the library could be mocked with test fixture. This is already done for fetchUrl and fetchPlone, but not for any higher level functions.

    Once it is possible to call more higher level functions with mock http interface, it should be possible to make that mock to serve the current JSON fixtures (from tests/gatsby-starter-default/fixture

    But first things first. That is the MVP :)

    As an almost unrelated thing, we just released the biggest GatsbyJS site so far: https://studyguide.jyu.fi/ (about 4000 pages)

    There is no Plone content there yet (current content comes Hasura-enhanced PostgreSQL database), but the roadmap includes also CMS-content and Plone is the most probable solution to manage that.

    Asko Soukka
    @datakurre

    Good that you manage with the TOKEN environment variable. I got good progress with adding security for the websocket support, but still more work to do.

    But this week I will have more time later, so I really hope this to be done by the next week.

    Alok Kumar
    @iFlameing

    As an almost unrelated thing, we just released the biggest GatsbyJS site so far: https://studyguide.jyu.fi/ (about 4000 pages)

    This is great :)

    Asko Soukka
    @datakurre

    @iFlameing Good news. You don't run out of work too soon.

    I added a couple of new tickets related to MVP.

    The first one is pretty easy and you can already simulate it by dropping the token.

    It is a valid use case that fetching URL from Plone returns Unauthorized or Forbidden. In gatsby develop this should result in deleting that node if that exists (so that pages changed to private would be removed from the site).

    The other one is trickier and needs more work. Currently Collection pages may "change" indirectly so there is no way to get update events for those from Plone. Updating those require scheduling (setTimeout) so that when ever there has been updates, after a small amount of time all known collections should be updated. (That means that whenever a new timeout is scheduled, the existing one should be cancelled so that update is run only once after a short period of time no more events from Plone).

    Alok Kumar
    @iFlameing
    @datakurre I have submitted the form of first evaluation :)
    Nilesh
    @nileshgulia1
    Hey @iFlameing , Congrats on first evaluation!
    Keep up the good work!
    Alok Kumar
    @iFlameing
    @nileshgulia1 thanks!
    @datakurre Since all the issue related to MVP is closed now, I am thinking that MVP is done now :tada: :tada: .
    Asko Soukka
    @datakurre
    @iFlameing Yes. Congratulations!
    So, what should you do next...
    Alok Kumar
    @iFlameing
    @datakurre I should start writing test for the added feature as we discuss earlier.
    can you guide me?
    How I can get started with it?
    Asko Soukka
    @datakurre
    @iFlameing Could you start by going through a few popular/official GatsbyJS source plugins to learn how they do their testing?
    I would guess that plugins they support for GatsbyJS Preview should be good quality enough to have some tests https://www.gatsbyjs.com/docs/#using-gatsby-preview
    Or maybe Wordpress one.
    All of those probably live inside the main GatsbyJS repository.
    Currently we have only a few simple unit tests for utils.js.
    Alok Kumar
    @iFlameing
    @datakurre ok!
    Asko Soukka
    @datakurre
    We are using jest https://jestjs.io/docs/en/getting-started but at least currently not snapshot tests. Just regular asserts.
    Snapshot tests are meant to test React component rendering.
    I assume we could continue to use jest for integration tests of gatsby-node API.
    Asko Soukka
    @datakurre

    @iFlameing So, please, use this week to review how the existing source plugins have been tested.

    Only then we should really decide, what kind of testing makes sense here.

    We already have high level acceptance tests for all the old features. I take the responsibility for upgrading that to support testing changes through websocket events. (That would be mainly bash scripting and Robot Framework, so for you that would be quite a step outside current JavaScript focus.)
    Most obvious choice would be to keep moving code from gatsby-node.js to utils.js or some other module and test those funtions with jest unit tests.
    But integration tests for the GatsbyJS API hooks in gatsby-node.js are still missing and there I would like GatsbyJS to provide some example or framework to do it right (and easily).
    Then again, another way for better quality would be to convert the project into typescript. It would probably have larger impact than having integration tests, but the amount of work in that is hard to estimate.
    Asko Soukka
    @datakurre
    @iFlameing So, because this is now only the first week of the second part of GSOC, I think it would be good to use a week to just learn the other plugins and then decide. If you run out of work, look into typescript also. This seemed to be a plugin using it https://github.com/sanity-io/gatsby-source-sanity
    Alok Kumar
    @iFlameing
    @datakurre okay! I will see the test written for different Gatsby-preview CMS and interact with GatsbyJS community for How we can write test for GatsbyJS API :)
    Asko Soukka
    @datakurre
    @iFlameing Thanks! After this week I would expect you to have an opinion on which way would make most sense (more testing, which kind of testing or just typescript).
    Alok Kumar
    @iFlameing
    @datakurre I will give my best In researching on these topics and develop my opinion about these different options.
    Asko Soukka
    @datakurre
    Great! Thanks!
    Alok Kumar
    @iFlameing
    @datakurre I read the test written for utils.js. I also read the documentation of jest. So, in my opinion we should write unit test first because it confirms that our logic is correct. Whether we use typescript we need to write unit test because typescript only ensure that whatever we returning from the function is of correct form but it doesn't ensure that our logic is correct. I asked Jason Lengstorf for integration tests for the GatsbyJs API and he replied "Each of the Gatsby APIs is a function, so you can unit test by importing and stubbing out Gatsby helpers. For integration testing, it would be easier to test the output (e.g. ensure pages were created by createPages). " I don't think I understand it fully. what should I do now?